[PATCH] D22918: [Loop Vectorizer] Support predication of div/rem

[Gil Rapaport via llvm-commits]

gilr added inline comments.

================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:4108-4115
@@ +4107,10 @@
+        continue;
+      bool CanSinkToUse = true;
+      for (User *U : OpInst->users()) {
+        if (U != &*I) {
+          // The extractelement is feeding another instruction - give up.
+          CanSinkToUse = false;
+          break;
+        }
+      }
+      if (CanSinkToUse)
----------------
anemet wrote:
> Is this any different than OpInst->hasOneUse?
Yes, for Instructions that use the same value more than once (see [[ https://reviews.llvm.org/D22918?id=65934#inline-195823 | Michael's comment ]]).

================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:4135-4138
@@ +4134,6 @@
+        IncomingFalse = IEI->getOperand(0); // the unmodified vector
+      } else {
+        // Phi node will be created for the scalar predicated instruction.
+        IncomingTrue = &*I;
+        IncomingFalse = UndefValue::get(I->getType());
+      }
----------------
anemet wrote:
> Is there a test for the non-insertelt case?
No. We currently always create an insertelement on scalarization. I added support for the non-insertelement case for completeness, since predication is done separately from scalarization.
IIUC this case will need to be supported if & when [[ https://reviews.llvm.org/D23169 | Matthew's patch ]] is committed, but for now it's really FFU.
I'll replace this case with an assertion for this patch and leave it to Matthew to resurrect in his patch as needed.


================
Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:4138
@@ +4137,3 @@
+        IncomingTrue = &*I;
+        IncomingFalse = UndefValue::get(I->getType());
+      }
----------------
anemet wrote:
> Why is the undef correct here?
We are re-introducing the original scalar conditional execution of an instruction here. This undef can reach either
- a select that will blend it out, or
- a Use dominated by this instruction's BB that is either
  - predicated by (at least) the same predicate, which won't use the undef, or
  - not predicated due to no side effects, where undef would be safe


https://reviews.llvm.org/D22918