[PATCH] D112734: [SCEVExpander] Drop poison generating flags when reusing instructions

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 28 10:07:27 PDT 2021


reames created this revision.
reames added reviewers: nikic, mkazantsev, fhahn.
Herald added subscribers: javed.absar, bollu, hiraditya, nemanjai, mcrosier.
reames requested review of this revision.
Herald added a project: LLVM.

This is a second attempt at the issue from D112637 <https://reviews.llvm.org/D112637>, but hopefully more correct this time.  :)

The basic problem we have is that we're trying to reuse an instruction which is mapped to some SCEV. Since we can have multiple such instructions (potentially with different flags), this is analogous to our need to drop flags when performing CSE. A trivial implementation would simply drop flags on any instruction we decided to reuse, and that would be correct.

This patch is almost that trivial patch except that we preserve flags on the reused instruction when existing users would imply UB on overflow already.  Adding new users can, at most, refine this program to one which doesn't execute UB which is valid.

In practice, this fixes two conceptual problems with the previous code: 1) a binop could have been canonicalized into a form with different opcode or operands, or 2) the inbounds GEP case which was simply unhandled.

This area of code is a tad more subtle than any of us would like, and my last attempt was definitely unsound.  I'd appreciate review with a skeptical eye.

On the test changes, most are pretty straight forward.  We loose some flags (in some cases, they'd have been dropped on the next CSE pass anyways).  The one that took me the longest to understand was the ashr-expansion test.  What's happening there is that we're considering reuse of the mul, previously we disallowed it entirely, now we allow it with no flags.  The surrounding diffs are all effects of generating the same mul with a different operand order, and then doing simple DCE.

The loss of the inbounds is unfortunate, but even there, we can recover most of those once we actually treat branch-on-poison as immediate UB.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112734

Files:
  llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp
  llvm/test/CodeGen/PowerPC/common-chain.ll
  llvm/test/Transforms/IRCE/non-loop-invariant-rhs-instr.ll
  llvm/test/Transforms/IndVarSimplify/ashr-expansion.ll
  llvm/test/Transforms/IndVarSimplify/lftr-address-space-pointers.ll
  llvm/test/Transforms/IndVarSimplify/lftr-reuse.ll
  llvm/test/Transforms/IndVarSimplify/pr24783.ll
  llvm/test/Transforms/IndVarSimplify/promote-iv-to-eliminate-casts.ll
  llvm/test/Transforms/LoopPredication/basic.ll
  llvm/test/Transforms/PhaseOrdering/loop-rotation-vs-common-code-hoisting.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D112734.383070.patch
Type: text/x-patch
Size: 25108 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211028/d7a60a66/attachment.bin>


More information about the llvm-commits mailing list