[PATCH] D104503: [SCEV] Don't require dominance ordering of add/mul/min/max expressions

[Philip Reames via Phabricator via llvm-commits]

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

I'm a bit hesitant about this patch, and welcome ideas on other approaches.

The test case test_non_dom demonstrates a case where scev-aa crashes today.  (If exercised either by -eval-aa or -licm.)  The basic problem is that SCEV-AA expects to be able to compute a pointer difference between two SCEVs for any two pair of pointers we do an alias query on.  For (valid, but out of scope) reasons, we can end up asking whether expressions in different sub-loops can alias each other.  This results in a subtraction expression being formed where neither operand dominates the other.

Looking at SCEV, I can't find a reason why the dominance invariant on operands is actually required.  The code which references it is simply a optimization rule, the worst that happens is we fail to caonicalize a hypothetical (i.e. not corresponding to an IR Value) expression.

This does result in somewhat odd scev expressions becoming possible.  For instance, the getMinusSCEV(getSCEV(%addr1), getSCEV(%addr2)) results in "({(-3200 + (-1 * %data)),+,-8}<nw><%subloop2> + {%data,+,8}<nw><%subloop1>)".  I can't find an immediate problem with that, but I am sorta wondering if I'm missing something here.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104503

Files:
  llvm/lib/Analysis/ScalarEvolution.cpp
  llvm/test/Analysis/ScalarEvolution/scev-aa.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D104503.352889.patch
Type: text/x-patch
Size: 5022 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210618/3e43046f/attachment.bin>