[PATCH] D38581: [IRCE] Fix intersection between signed and unsigned ranges

Anna Thomas via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 19 08:10:53 PDT 2017


anna requested changes to this revision.
anna added a comment.
This revision now requires changes to proceed.

Some clarification questions and comments inline.



================
Comment at: lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp:1753
+  auto RangeIsNonNegative = [&](InductiveRangeCheck::Range &R) {
+    return SE.isKnownNonNegative(R.getBegin()) &&
+           SE.isKnownNonNegative(R.getEnd());
----------------
mkazantsev wrote:
> mkazantsev wrote:
> > anna wrote:
> > > Is this enough for proving range is non-negative?
> > > 
> > > Looking at this lambda alone with no context here, we can have [5, 2] and still have range wrap around.
> > > Is there a way to add an assert that getBegin < getEnd?
> > In `parseLoopStructure` we assert that the IV `HasNoSignedWrap`. Interesting detail is that currently it only checks for `nsw`. My guess is that we should check `nuw` for unsigned IVs instead. I will check with that and possibly add some tests.
> > 
> > But generally, we assume that the IV does not have wraparound, and ranges for range checks are also in canonical form from a smaller value to a greater value.
> Thanks for pointing this situation out! Indeed, it wasn't handled before. As result, sometimes IRCE applied to safe ranges like `[5, 2)` ending up with making completely unprofitable transformations.
> 
> We cannot assert that `Begin < End` because in the most common situation we don't know it (for example, iteration from 0 to `N` where `N` is non-negative is potentially an empty loop, as well as iteration from `A` to `B`; we might be not able to say anything from SCEVs, however if we knew that we iterated from `A` to `B` with `nsw` flag, that would give us this piece of information). So this check is over-conservative. 
> 
> Rather than asserting that `Begin < End` which is not always known without context (about the indvar and so on), I've prepared a patch https://reviews.llvm.org/D39082 that trats ranges for which we know that `Begin >= End` as empty.
> 
thanks for the clarification! I have added comments on the other review thread about detecting empty ranges.


================
Comment at: test/Transforms/IRCE/unsigned_comparisons_ult.ll:345
+  store i32 0, i32* %addr
+  %next = icmp ult i32 %idx.next, -100
+  br i1 %next, label %loop, label %exit
----------------
Am I right that because of the ult for the compare, -100 is actually UINT_MAX - 99, i.e. the 2's complement of the number. 
So, the iteration space is within [0, SINT_MAX].


================
Comment at: test/Transforms/IRCE/unsigned_comparisons_ult.ll:360
+
+; CHECK:      test_09
+
----------------
Please add checks here as `CHECK-NOT` for pre and post loops.


https://reviews.llvm.org/D38581





More information about the llvm-commits mailing list