[PATCH] D17201: [SCEV] Introduce a guarded backedge taken count and use it in LAA and LV

[Sanjoy Das via llvm-commits]

sanjoy added inline comments.

================
Comment at: test/Transforms/LoopVectorize/X86/vectorization-remarks-missed.ll:54
@@ -53,3 +53,3 @@
 for.body:                                         ; preds = %entry, %for.body
   %indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 0, %entry ]
   %arrayidx = getelementptr inbounds i32, i32* %A, i64 %indvars.iv, !dbg !16
----------------
sbaranga wrote:
> I had to change this test because it started to figure out what the backedge taken count was.
> 
> This was testing the vectorization remark when we cannot find the backedge taken count. changed the test so that it will continue not be able to get the backedge taken count.
> 
> What is interesting about this is the way we've managed to get the (exact) backedge taken count. The initial analysis was only able to get the maximum backedge taken count but not the exact one. However, we can use this to get a better SCEV for cmp3.
> 
> On a following invocation of computeBackedgeTakenCount this information is used to get an exact backedge taken count.
Interesting.  Do you mean "However, we can use this to get a better
SCEV for `%0`"?  I can see how `SimplifyICmpOperands` would be able to
use a tighter range on `%0` to simplify the `sle` into an `slt`.

It would be great if SCEV could directly compute the backedge count
here though.  The problem is that we didn't have a way for
`computeExitLimitFromCond` to say "BECount is Infinite if `L` is
`INT_MAX` else is `L + 1` (say)" so `computeExitLimitFromCond` would
have to give up in the face of the dreaded `COULDNOTCOMPUTE`.  But
with your work, that is changing (ability to represent predicated BE
counts); and perhaps one day SCEV will be able to directly compute the
backedge taken counts of loop like these. :)



http://reviews.llvm.org/D17201