[PATCH] D84451: [LV] Tail folded inloop reductions.

Dave Green via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 22 01:02:47 PDT 2020


dmgreen added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:6956-6967
+    auto OldInsertionPoint = Builder.getInsertPoint();
+    auto NewInsertionPoint = Builder.getInsertBlock()->begin();
+    // Create the block in mask as the first non-phi instruction in the block.
+    while (NewInsertionPoint != Builder.getInsertBlock()->end() &&
+        (NewInsertionPoint->getVPRecipeID() == VPRecipeBase::VPWidenPHISC ||
+         NewInsertionPoint->getVPRecipeID() ==
+             VPRecipeBase::VPWidenIntOrFpInductionSC ||
----------------
dmgreen wrote:
> This code is a bit of a mess, and is causing a lot of the test differences. It's here to try and enforce that the block mask is always created before the reduction intrinsic, even if the reduction is inserted at the point of an existing binary operation. Without this we can end up with situations where the select does not dominate the block mask it is using.
> 
> I don't really like this change - it puts too much of a required ordering into these nodes - but I'm not sure of a better way to handle it. I tried a few ways without much success. Because we usually only get access to a VPValue, not the VPRecipe it represents, moving the recipe (and all dependent recipes) after the fact doesn't seem to be simple either.
> 
> Any thoughts/suggestions?
I've tried to clean this up using a getFirstNonPhi and InsertPointGuard.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84451/new/

https://reviews.llvm.org/D84451



More information about the llvm-commits mailing list