[PATCH] D46827: [VPlan] Add VPInstruction to VPRecipe transformation.

Satish K Guggilla via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 15 10:11:42 PDT 2018


sguggill added a comment.

The changes look good to me. I have also verified that my outer loop vector code generation changes work with these changes after some minor modifications.



================
Comment at: lib/Transforms/Vectorize/VPlanHCFGTransforms.cpp:76
+      Instruction *Inst = dyn_cast<Instruction>(VPInst->getUnderlyingValue());
+      if (DeadInstructions.count(Inst) || isa<DbgInfoIntrinsic>(Inst)) {
+        Ingredient->eraseFromParent();
----------------
fhahn wrote:
> sguggill wrote:
> > dcaballe wrote:
> > > Shoudn't we collect DbgInfoIntrinsic as a DeadInstructions instead of having this check here?
> > An assert(inst) would be nice here.
> Switched to cast<>
OK.


================
Comment at: lib/Transforms/Vectorize/VPlanHCFGTransforms.cpp:94
+      } else
+        NewRecipe = new VPWidenRecipe(Inst);
+
----------------
dcaballe wrote:
> fhahn wrote:
> > sguggill wrote:
> > > I think we are diverging from the nonVPlanNativePath case, where a widenRecipe can have > 1 ingredients but this should be fine.
> > Yep, this code creates a new WidenRecipe for each widened instruction because it is slightly more work to get the previous recipe, because we remove the current instruction. I can change it though if you think that's better.
> You mean in line 95? I see. We shouldn't create unnecessary recipes if we can reuse an existing one. Could we do something similar to the code at the end of 'tryToWiden'?:
> 
> ```
>   // Success: widen this instruction. We optimize the common case where
>   // consecutive instructions can be represented by a single recipe.
>   if (!VPBB->empty()) {
>     VPWidenRecipe *LastWidenRecipe = dyn_cast<VPWidenRecipe>(&VPBB->back());
>     if (LastWidenRecipe && LastWidenRecipe->appendInstruction(I))
>       return true;
>   }
> 
>   VPBB->appendRecipe(new VPWidenRecipe(I));
> ```
This looks good. Thanks!


https://reviews.llvm.org/D46827





More information about the llvm-commits mailing list