[PATCH] D15412: [SCEV][LAA] Add no overflow SCEV predicates and use use them to improve strided pointer detection

[silviu.baranga@arm.com via llvm-commits]

sbaranga added a comment.

Hi Sanjoy,

Sorry for the delayed reply (holidays..). I should have a new version of this up for review soon.

Thanks,
Silviu


================
Comment at: include/llvm/Analysis/ScalarEvolution.h:282
@@ +281,3 @@
+    ///
+    /// In the integer domain this is equivalent to 0 <= a + b < 2^n
+    ///
----------------
sanjoy wrote:
> I'd be a lot more explicit here.  What (I think) you're saying is that
> 
> ```
> 0 <= F(a) + F(b) < 2^n
> ```
> 
> where the inequalities and arithmetic above are normal inequalities and arithmetic over integers, and `F` maps an `n` bit tuple to the integer it represents in twos complement.
> 
> Is that correct?
I think almost correct. You would technically need a different function for a, since we regard it as unsigned. So that means

0 <= G(a) + F(b) < 2^n, where F maps to twos complement and G is simple base 2 conversion.

Some examples:

So for a 16-bit example of a = 0xffff and b = 0xfffe we would get F(0xffff) = 2^16 - 1 and G(0xfffe) = -2 and
0 <= 2^16 - 3 < 2^16 which is satisfied.

For a = 0x0, b = 0xffff we get

0 <= -1 < 2^16 which is false.

For a = 0xffff, b = 0x0010 we get

0 <= 2^16 -1 + 2 < 2^16 which is false.

Does this make sense to you?

================
Comment at: include/llvm/Analysis/ScalarEvolution.h:1453
@@ -1369,1 +1452,3 @@
+    /// Records what NoWrap flags we've added to a Value *.
+    DenseMap<Value *, SCEVWrapPredicate::NoWrapFlags> FlagsMap;
     /// The ScalarEvolution analysis.
----------------
sanjoy wrote:
> Will clients ever try to RAUW / delete `Value` s from under this map.  If not, this should be changed to use an `AssertingVH`; otherwise it needs to use a `CallbackVH` like SCEV.
I think AssertingVH would make the most sense here.


http://reviews.llvm.org/D15412