This change is dependent on http://reviews.llvm.org/D5638
If x is known to have the range [a, b), in a loop predicated by (icmp ne x, a) its range can be sharpened to [a + 1, b). Get ScalarEvolution and hence IndVars to exploit this fact.
Differential D5639
Teach ScalarEvolution to sharpen range information. sanjoy on Oct 6 2014, 7:09 PM. Authored by
Details
This change is dependent on http://reviews.llvm.org/D5638 If x is known to have the range [a, b), in a loop predicated by (icmp ne x, a) its range can be sharpened to [a + 1, b). Get ScalarEvolution and hence IndVars to exploit this fact.
Diff Detail Event Timeline
Comment Actions There are a couple obvious typos. Please make sure those are fixed to match your intentions. Otherwise, I think this is fine. I have to admit I had to stare at it for quite some time to understand what's going on, but it does seem like a decent fix for your reasonable test case. [off the subject of the review a bit]
Comment Actions Will fix, thanks! Just to be clear -- is this okay to check in after those changes or should I re-upload for review?
An interesting thing related to the test case: if you change the entry block to entry: %length = load i32* %buffer ;; this line changed (!range removed) %entry.pred = icmp slt i32 %length, 1 ;; this line changed (eq => slt) br i1 %entry.pred, label %abort, label %loop.preheader llvm TOT at -O3 will optimize away %oob.pred just fine. But adding the !range metadata makes -instcombine kick in and optimize %length slt 1 to %length eq 0 (the two are equivalent if the msb of %length is 0) clobbering the -indvars optimization. So, on llvm TOT, there is at least one case where adding a !range annotation regresses performance at -O3. This patch fixes that issue too.
Thanks, will keep that in mind. Comment Actions This change broke the PushAndPopWithPoisoningTest asan unit test, so I reverted it. I'm looking into why it broke.
Comment Actions The bug was that the code in the switch...case invoking isImpliedCondOperands assumed Min was the unsharpened minimum. This version of the patch fixes the issue and adds a regression test that would've caught the bug. The earlier patch was also needlessly complex -- I've simplified the code structure in this revision. Sorry for the confusion! |
You mean "not equal to a"?