[PATCH] D12210: [InstCombine] Transform A & (L - 1) u< L --> L != 0

[Sanjoy Das via llvm-commits]

sanjoy added inline comments.

================
Comment at: test/Transforms/InstCombine/ult-and-bitwise-and.ll:5
@@ +4,3 @@
+; CHECK: @f(
+  %lim.sub = add i32 %lim, -1
+  %val.and = and i32 %val, %lim.sub
----------------
reames wrote:
> Add a version of this test case with sub 1.
> 
> I think you need the fact that %lim is >= 0 for this to hold.  Consider %lim with 0x101 and %val of 0x110.  The original check fails, yours succeeds.  
> 
> Also, I think that if the add is nsw, we can infer lim is > 0 and thus directly fold to true.  
> Add a version of this test case with sub 1.

Good idea, done (+ moved to `icmp.ll` as David suggested)

> I think you need the fact that %lim is >= 0 for this to hold. Consider %lim with 0x101 and %val of 0x110. The original check fails, yours succeeds.

The original succeeds also -- the check is with `val & (lim - 1)` == `0x110 & 0x100` = `0x100` u< `lim`.  `val & (lim - 1)` will always have a lesser or equal number of ones in its binary representation than `lim - 1` and hence always will be ULE than `lim - 1`.  `lim - 1` is ULT than `lim` iff `lim` != `0`.  Thus `val & (lim - 1)` ULT `lim` iff `lim != 0`.

> Also, I think that if the add is nsw, we can infer lim is > 0 and thus directly fold to true.

`add nsw i32 0, -1` is not poison.  I could do that inference if the instruction was `sub nuw %lim, 1`, but the `sub` will get canonicalized to `add`, and the `nuw` will then have to be dropped.

In any case, I'd rather not be aggressive about exploiting `nuw` and `nsw` unless there is good reason showing that it matters.


http://reviews.llvm.org/D12210