[all-commits] [llvm/llvm-project] 767745: [ConstantFolding] Do not consider padded-in-memory...

[Björn Pettersson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7677453886a665b37f22c77434b36a680aba6ebb
      https://github.com/llvm/llvm-project/commit/7677453886a665b37f22c77434b36a680aba6ebb
  Author: Björn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2024-02-15 (Thu, 15 Feb 2024)

  Changed paths:
    M llvm/include/llvm/Analysis/ConstantFolding.h
    M llvm/lib/Analysis/ConstantFolding.cpp
    M llvm/lib/Analysis/InstructionSimplify.cpp
    M llvm/lib/Transforms/IPO/Attributor.cpp
    M llvm/lib/Transforms/IPO/GlobalOpt.cpp
    M llvm/test/Transforms/InstSimplify/ConstProp/loads.ll

  Log Message:
  -----------
  [ConstantFolding] Do not consider padded-in-memory types as uniform (#81854)

Teaching ConstantFoldLoadFromUniformValue that types that are padded in
memory can't be considered as uniform.

Using the big hammer to prevent optimizations when loading from a
constant for which DataLayout::typeSizeEqualsStoreSize would return
false.

Main problem solved would be something like this:
  store i17 -1, ptr %p, align 4
  %v = load i8, ptr %p, align 1
If for example the i17 occupies 32 bits in memory, then LLVM IR doesn't
really tell where the padding goes. And even if we assume that the 15
most significant bits are padding, then they should be considered as
undefined (even if LLVM backend typically would pad with zeroes).
Anyway, for a big-endian target the load would read those most
significant bits, which aren't guaranteed to be one's. So it would be
wrong to constant fold the load as returning -1.

If LLVM IR had been more explicit about the placement of padding, then
we could allow the constant fold of the load in the example, but only
for little-endian.

Fixes: https://github.com/llvm/llvm-project/issues/81793