[all-commits] [llvm/llvm-project] e1cc9e: [ConstantFold] Remove non-trivial gep-of-gep fold ...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e1cc9e4eaddcc295b4e775512e33b947b1514c17
      https://github.com/llvm/llvm-project/commit/e1cc9e4eaddcc295b4e775512e33b947b1514c17
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2024-05-31 (Fri, 31 May 2024)

  Changed paths:
    M clang/test/CodeGenCXX/2011-12-19-init-list-ctor.cpp
    M clang/test/CodeGenCXX/cxx0x-initializer-stdinitializerlist-pr12086.cpp
    M clang/test/CodeGenCXX/cxx0x-initializer-stdinitializerlist.cpp
    M clang/test/OpenMP/threadprivate_codegen.cpp
    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:
  -----------
  [ConstantFold] Remove non-trivial gep-of-gep fold (#93823)

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