[PATCH] D67178: [SCEV] Use loop guard info when computing the max BE taken count in howFarToZero.

[Florian Hahn via Phabricator via llvm-commits]

fhahn updated this revision to Diff 292596.
fhahn added a comment.

Finally had some time to get back to this one. Rebased and also added SCEV test for PR40961. I will also post a follow-up that extends this to also support assumes to catch PR47247.

Sorry for the long delay! There is still bits that can be improved (e.g. sharing code with isLoopEntryGuardedByCond), but I'd like to converge on the general approach before focusing on that.

In D67178#1670316 <https://reviews.llvm.org/D67178#1670316>, @reames wrote:

> SCEV already has support for isLoopEntryGuardedByCond which should be a super set of the added code.

Yes, this code here is similar to isLoopEntryGuardedByCond in that it looks at the same information (conditions dominating the loop body). But it is also different conceptually I think. isLoopEntryGuardedByCond is useful, if we known which question to ask, e.g. we could use the loop guards to check if an expressions is less than a constant (but we need to know which specific constant/condition to check).

Unfortunately I do not think this is very useful to clamp the range of the expressions at hand here, because it would require both explicitly checking what information is available through guards, as well as checking how it is used in the expression.

The approach of applyLoopGuards is different: the idea is to re-write an expression with information from the loop guards and use the existing reasoning to try to use the additional info to simplify the overall expression. This approach seems quite effective and allows for all the existing simplification logic to be completely reused.

> Have you explored why the distance expression isn't be canonicalized at construction?
>
> (There are some circularity issues between exit counts and scev canonical forms, so that might be your issue.  Or it might be something easy to fix.  We can always hope.)

I thought about this one a bit more. I am not sure any general canonicalization is missing here, because the information we apply here is very context specific: we can use information from the guards, because we construct an expression that is only valid in the loop body. And the backedge taken count is a artificial expression we are building up specifically in howFarToZero (and it's sibling functions). Unless I am missing something,  I don't think there is any general canonicalization that is missing here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67178

Files:
  llvm/include/llvm/Analysis/ScalarEvolution.h
  llvm/lib/Analysis/ScalarEvolution.cpp
  llvm/test/Analysis/ScalarEvolution/max-backedge-taken-count-guard-info.ll
  llvm/test/CodeGen/X86/optimize-max-0.ll
  llvm/test/Transforms/LoopVectorize/AArch64/pr36032.ll
  llvm/unittests/Analysis/ScalarEvolutionTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D67178.292596.patch
Type: text/x-patch
Size: 24379 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200917/0f8f65db/attachment-0001.bin>