This was suggested as a DAG simplification in the review for rL297026 :
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170306/435253.html
...but let's start with IR since we have actual docs for IR (LangRef).
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Would that mean that this transformation (very naive SLP vectorization) would become illegal:
%z1 = urem i8 %x1, %y1 %z2 = urem i8 %x2, %y2 ret i8 %z1
Into:
%vx1 = insertelement <2 x i8> undef, i8 %x1, i32 0 %vx2 = insertelement <2 x i8> %vx1, i8 %x2, i32 1 %vy1 = insertelement <2 x i8> undef, i8 %y1, i32 0 %vy2 = insertelement <2 x i8> %vy1, i8 %y2, i32 1 %vz = urem <2 x i8> %vx2, %vy2 %z = extractelement <2 x i8>%vz, i32 0 ret i8 %z
?
I'm not sure this is something we want.
Would that mean that this transformation (very naive SLP vectorization) would become illegal:
Why would that be illegal? Both snippets have undefined behavior if and only if y1 or y2 is zero (or undef, or poison).
Er, right, bad example. Let me think if I have a good one. What I'm aiming at is that I don't want to propagate undef from a lane that's never used into a lane that's actually used.
The logic goes something like this: division by zero is undefined behavior, therefore the instruction is unreachable, therefore we can replace all uses with undef.
I had the same concern. I was remembering something like this:
https://bugs.llvm.org/show_bug.cgi?id=20059
...but we solved that by limiting the transform with isSafeToSpeculativelyExecute(). That's what protects us from Bad Things with any div/rem. If there's some other transform that makes us use a value from a lane that shouldn't have been touched, then it must already be wrong?