[PATCH] D111186: [SCEV] Infer flags from add/gep in any block

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 6 10:42:17 PDT 2021


reames added a comment.

In D111186#3045847 <https://reviews.llvm.org/D111186#3045847>, @nikic wrote:

>> The comment is also suspect as well in that we're in the middle of constructing a SCEV for I. As such, we're going to visit all operands *anyways*.
>
> I can only make a guess here, but what this might be referring to is the fact that SCEV construction from IR will coalesce add/sub and mul expressions into a single call of getAddExpr/getMulExpr rather than building up a chain of binary adds/muls. Effectively, the change you do here defeats that (for the case where the IR instruction has flags, even if they are inapplicable), because you will end up calling getSCEV on each individual add due to the operand fetch in the poison check.

So, while reasonable, this isn't quite right or at least isn't so any longer.  When constructing an add reduction tree, we will aggressively collapse into a single add node, dropping flags as needed.  This is done inside getAddExpr.  The code that runs during parsing - which goes out of it's way to separate by flag type - appears to just be canonicalized back into the flattened form )if not all flags match).  Now, maybe there's a difference in the number of nodes from the interior of the tree formed, but that cost should be *very* minimal.  (As for one thing, how would you construct an add tree with a non-SCEVable operand type?)

("add" can be replaced with "arithmetic operation" in the above to generalize)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111186



More information about the llvm-commits mailing list