[PATCH] D115757: [SLP]Generalize cost model.

Simon Pilgrim via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 10 09:57:47 PDT 2022


RKSimon added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6401
+       this](InstructionCost CommonCost) {
+        ScalarizationOverheadBuilder ScalarizationCost;
+        for (unsigned Idx = 0; Idx < Sz; ++Idx) {
----------------
I'm sorry but I had to revert the ScalarizationOverheadBuilder code - this needs reverting back to the older version


================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:5840
+    if (!I)
+      return true;
     auto *Op = cast<Instruction>(V)->getOperand(OpIdx);
----------------
ABataev wrote:
> RKSimon wrote:
> > ABataev wrote:
> > > RKSimon wrote:
> > > > true?
> > > Here is my idea. Generally speaking, here we can have only undef/poison or just a pointer (as part of getelementpr node) currently (maybe, need to add an assert). I thought that because of that we can treat its (virtual) operand as power-of-2, since it can be any value. Thoughts?
> > Still not sure about this - this undef case is fine, but the GEP I can imagine might not work in all special cases.
> > 
> > How good is return isa<UndefValue>(V); instead?
> GetElementPtr may have just a pointer, which is not a GEP instructions.
> Say, we have this:
> ```
> void @foo(ptr %v) {
> ...
> load %v
> %n = getelementptr i32, ptr v, 1
> load %n
> ...
> }
> ```
> and we may have a ПУЗ node which includes {%v, %n}. Here %v is not a GEP though still part of the GEP node and we consider as `gentlementptr ptr %v, 0`.
OK - so for GEPs you're saying that either the operands will be constant or a phi of constants?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115757



More information about the llvm-commits mailing list