[PATCH] D114253: [LV] Check VPValue operand instead of Cost::isUniformAfterVec (NFC).

Ayal Zaks via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 30 01:00:36 PST 2021


Ayal added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3173
+    VPValue *Op = I.value();
+    auto RepR = dyn_cast_or_null<VPReplicateRecipe>(Op->getDef());
+    if (!Op->getDef() || (RepR && RepR->isUniform()))
----------------
fhahn wrote:
> Ayal wrote:
> > Whether a VPValue is "uniform after vectorization" or not should probably be a property of VPValue. Currently this can indeed be detected in VPlan by checking if it has no recipe, or has a uniform replicating recipe. Worth wrapping in a method or function? Its implementation may change when VPValues obtain "type" information and/or when additional scalar recipes may be introduced.
> > 
> > Current patch is ok, as a temporary step; would be good to add a comment.
> > 
> > `Op` may be confused with Operation; perhaps the original `Operand` would be better.
> > `RepR` may be confused with `RepRecipe`; perhaps `OperandRepR` would be better.
> > 
> > Whether a VPValue is "uniform after vectorization" or not should probably be a property of VPValue
> 
> Good point! I move the check logic to `VPlan::isUniformAfterVectorization`, to avoid tying this directly to the information available for a VPV. Was this what you had in mind by moving it into a function?
Yes, it was. Note that in D104254, UAV's (as opposed to truly uniforms) are identified by looking for the address operands of widened memory recipes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114253



More information about the llvm-commits mailing list