[all-commits] [llvm/llvm-project] cc158d: Reapply [ConstantFold] Remove non-trivial gep-of-g...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: cc158d4c0bb50554dadcad44c10cafb052376cea
      https://github.com/llvm/llvm-project/commit/cc158d4c0bb50554dadcad44c10cafb052376cea
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2024-06-10 (Mon, 10 Jun 2024)

  Changed paths:
    M llvm/lib/IR/ConstantFold.cpp
    M llvm/test/Other/constant-fold-gep.ll
    M llvm/test/Transforms/InstCombine/gepgep.ll
    M llvm/test/Transforms/InstCombine/getelementptr.ll
    M llvm/test/Transforms/InstCombine/ptrtoint-nullgep.ll

  Log Message:
  -----------
  Reapply [ConstantFold] Remove non-trivial gep-of-gep fold (#93823)

Reapply after https://github.com/llvm/llvm-project/pull/93956, which
changed clang array initialization codegen to avoid size regressions
for unoptimized builds.

-----

This fold is subtly incorrect, because DL-unaware constant folding does
not know the correct index type to use, and just performs the addition
in the type that happens to already be there. This is incorrect, since
sext(X)+sext(Y) is generally not the same as sext(X+Y). See the
`@constexpr_gep_of_gep_with_narrow_type()` for a miscompile with the
current implementation.

One could try to restrict the fold to cases where no overflow occurs,
but I'm not bothering with that here, because the DL-aware constant
folding will take care of this anyway. I've only kept the
straightforward zero-index case, where we just concatenate two GEPs.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications