[PATCH] D140789: [SLP] Unify GEP cost modeling for load, store and GEP nodes.

[Valeriy Dmitriev via Phabricator via llvm-commits]

vdmitrie added a comment.

F26086937: 02.pdf <https://reviews.llvm.org/F26086937>



================
Comment at: llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:6893-6898
+      // When GEP used more than once it won't be removed after vectorization
+      // (should we check that all uses are inside vec tree instead?).
+      // GEPs with all constant indices also considered to have zero cost.
+      // TODO: it is target dependent, so need to implement and then use a TTI
+      // interface.
+      if (Ptr && Ptr->hasOneUse() && !Ptr->hasAllConstantIndices())
----------------
ABataev wrote:
> If pointer has multiple uses, it still will be vectorized + added the cost of the external use. I think currently, we still may add the cost of the external use for such geps. Shall we drop Ptr->hasOneUse() for some nodes, like scattervectorize, but not for vector loads/stores?
We shall treat GEP is not a regular instruction. For regular instruction we can perform vector operation and than extract a lane to get a value. We cannot do the same for a GEP. When scalar GEPs has just one use it means that their user will be removed as a result of vectorization. But this does not happen for GEPs as there is no vector version of GEP exists. Instead we just cast base pointer to required vector type. If some non-base pointer GEPs have more that one use that means they may still have uses after the tree was vectorized (i.e. GEP will not be removed). That is my understanding about what logic was put behind that hasOneUse check. I agree that it can be not quite satisfactory and I left the comment about "all uses inside vectorizable tree". In this regard test case geps-non-pow-2.ll probably represents an exception from the above as GEPs are arguments of PHIs (and we do not really know what is relationships between the GEPs) and an external use will produce an extract rather than leaves the original GEP instruction.  Note that in this case all nodes in the tree are either "vectorize" or splats (See attached pdf). I.e. we probably may drop hasOneUse when an in-tree user of GEPs is PHI but I believe it would be incorrect to do that if GEP user is a load/store node (regardless of vectorize/scattervectorize kind).




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140789