[PATCH] D114766: If constrained intrinsic is replaced, remove its side effect

Kevin P. Neal via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 30 07:45:20 PST 2021


kpn added a comment.

Well, the problem is more widespread than that. IPSCCP can create instructions where it knows the result, and it knows the instruction will never trap. Consider how it can propagate two constants into a compare instruction. It knows the values are constants, it knows they are not undef, poison, NaN, Inf, it knows the value of the compare, and it uses that knowledge to further propagate constants and simplify the code. But it can't remove the constrained compare instruction because we don't have a good way to tell it the instruction has no side effects. It does call Instruction::isSafeToRemove(), and it does _not_ call wouldInstructionBeTriviallyDead(). A more centralized approach would be helpful.

Perhaps a way of asking the constrained intrinsic if it has a side effect? Then we can even eliminate constrained intrinsics that are "fpexcept.strict" but are known to never trap. This isn't ideal, either, but it's my current line of thinking, anyway. I don't have a really good solution.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114766/new/

https://reviews.llvm.org/D114766



More information about the llvm-commits mailing list