Noticed this while working on another patch. Was originally going to just land it, but it seemed a little too obvious and I'm tired. Is there something I'm missing here?
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
2398 | Why the IsKnownNonNegative check for the NUW case? Shouldn't this be on NSW? |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
2393–2394 | Comment implies that the step must be non-negative in both cases, |
For the record, this
isn't approval. There's 'accept revision' for that.
I'm not sure just how much more softly do i need to word that message to convey that.
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
2398 | We definitely need it for NSW - I'd apparently dropped it for the NSW case when rebasing this. Oops. For the unsigned case, I'll be honest and say I'm not sure. I get really confused about the interpretation of the signed integer overflow rules on add. The case I was thinking of was starting at 0, and adding -1. Does that violate nuw or not? If it does, we need the positive check. If it doesn't, we probably don't. Now that I write this, I'm pretty sure the answer is we don't, but I regularly get confused by that case, so I'll let someone else confirm. :) Keeping in mind that SCEV and IR mix flag interpretations oddly, I'm strongly tempted to keep the non-negative test for (my) sanity sake even if we don't strictly speaking need it. |
Sorry I misread your intent. It certainly read like approval to me, but well, my screw up. Reverted, and review resumed. Will wait for an explicit LGTM.
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
2398 | If you think about it as not adding 0 and -1, but rather 0 and 0xffffffff, then it becomes more obvious that it's nuw. I'd prefer not having an unnecessary isKnownNonNegative check here -- doing sign checks for unsigned arithmetic is usually an indication that some logic isn't right... (And if we don't need to check the sign, we can drop the Ops.size() == 2 limitation for the nuw case as well.) |
Implement review comment and narrow scope to nuw only.
I'll come back to the nsw case separately, but a) nuw is what's actually blocking me, and b) with the focus on generality in the review comments, we should do the same for nsw which requires a bit more code motion than I want to roll into this patch.
Now this i don't think is right.
llvm/test/Transforms/IndVarSimplify/widen-loop-comp.ll | ||
---|---|---|
514 ↗ | (On Diff #368404) | Alive doesn't like this |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
2398 | Okay, looks like I was wrong here! The bit I was missing is that nw is actually a signed property: /// AddRec expressions may have a no-self-wraparound <NW> property if, in /// the integer domain, abs(step) * max-iteration(loop) <= /// unsigned-max(bitwidth). This means that the recurrence will never reach /// its start value if the step is non-zero. Computing the same value on /// each iteration is not considered wrapping, and recurrences with step = 0 /// are trivially <NW>. <NW> is independent of the sign of step and the /// value the add recurrence starts with. Note the abs(step) in the definition. So we do need to ensure that the step is non-negative, to make sure that abs(step) is just step. |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
2398 | Yeah, I'd just worked my way to the same conclusion. For my own future reference, here's the chain of logic. no-self-wrap is a property which describes the space traversed. It is not a wrapping property per se. (0,+, 255) in 8 bit math represents a value which decreases by one on each iteration (by wrapping through unsigned). Putting NUW on this generates poison on the 2nd iteration. NW on the other hand, is not violated because the number of values traversed (assuming BTC is small) is less than 255. We need the non-negative restriction to line up the restriction in terms of values traversed with the NUW definition. |
Add back the positive restriction. The affine restriction could possibly be relaxed in the future.