[PATCH] D48853: [SCEV] Add zext(C + x + ...) -> D + zext(C-D + x + ...)<nuw> transform

Roman Tereshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 3 09:42:03 PDT 2018


rtereshin added inline comments.


================
Comment at: lib/Analysis/ScalarEvolution.cpp:1813
+      // KnownBits 0000 00XX, loosing Min: 1, Max: 2 to Min: 0, Max: 3.
+      // So use both if available:
+      if (OpV) {
----------------
rtereshin wrote:
> rtereshin wrote:
> > Another thing to discuss here is the fact that SCEV appears to be relying on value range analysis implemented via `ConstantRange` instead of `KnownBits`. It appears to me that we could achieve better results if we used //both// simultaneously updating them properly. See the example above justifying that.
> > 
> > Do you think it's worth bringing up at dev mailing list level?
> Now's the adventurous bit: KnownBits is able to prove that C1 + (C2 * 2^n * X) doesn't wrap if C1 < 2^n precisely because KnownBits operates over the arithmetic base of 2. If KnownBits operated over base of 3, for example, we could use it to prove that C1 + (C2 * 3^n * X) doesn't wrap (for instance, u * 3 + 1. Indeed, if bits of 3 are all unknown, KnownBits<base 3> of (u * 3) is XXXX XXX0 and therefore u * 3 + C doesn't wrap for any C <- {0, 1, 2}). I suspect that it could be proven that there is a basis (in linear algebra sense) in the system of KnownBits' that is sufficient: KnownBits over prime numbers.
> 
> So let's say for every SCEV expression we cache not just ConstantRange, but every non-trivial KnownBits<B>, where B (the base) <- {p1, p2, ..., pK}, p<i> is i-th prime number, K is some reasonable limit, and "non-trivial" means "not all bits (or rather digits) are unknown", and we use that information to effectively restore <nuw>/<nsw> flags where needed.
Ah, I just realized that due to the unfortunate fact that (2^4 - 1) is divisible by 3 and 5, KnownBits over base 3 won't allow us to prove that 3*u + 1 doesn't wrap, as it very well may. It will allow us to prove though that 3*u + 1, 3*u + 2, and 3*u + 3 are consecutive, but it's probably not as useful as if we could start from 0. Same for base 5.


Repository:
  rL LLVM

https://reviews.llvm.org/D48853





More information about the llvm-commits mailing list