[LLVMdev] Missed vectorization opportunities?

[Sanjoy Das]

> I expect SCEV treats them differently because of MAX_INT handling.
> Look as the definedness of both if n == MAX_INT. The first has
> undefined behavior, the second does not.
> If you change the second into the first, you introduce undefined behavior.
> (or maybe it's implementation defined, but whatever)

To elaborate a little further on this:

In the first loop, you can never enter the loop with "j == INT_SMAX"
since INT_SMAX will never be < anything.  This means j + 1 cannot
overflow.  In the second loop you /can/ enter the loop with "j ==
INT_SMAX" if "n == INT_SMAX" so j + 1 can potentially overflow.

Ideally SCEV should be able to infer the nsw'ness of the additions
from the nsw bits in the source IR; but that's more complex that it
sounds since SCEV does not have  a notion of control flow within the
loop and it hashes SCEVs by the operands and not by the nsw/nuw bits.
Crude example:

define void @x(i32 %a, i32 %b, i1 %c) {
 entry:
  %m = add i32 %a, %b
  br i1 %c, label %do, label %dont

 do:
  %m1 = add nsw i32 %a, %b
  br label %dont

 dont:
  ret void
}

both %m and %m1 get mapped to the *same* SCEV, and you cannot mark
that SCEV as nsw even though %m1 is nsw.

-- Sanjoy



>
>
> This is the:
>   if (!getUnsignedRange(RHS).getUnsignedMax().isMaxValue()) {
>
> check in that function simplify.
>
> But you should file a bug anyway.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev