[PATCH] D53865: [LoopVectorizer] Improve computation of scalarization overhead.

Hideki Saito via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 10 10:57:35 PST 2018


hsaito added a comment.

In D53865#1312568 <https://reviews.llvm.org/D53865#1312568>, @jonpa wrote:

> > Making better decisions what to vectorize and what to keep scalar is clearly useful enough to include in the loop vectorizer. However, this should best be done in a target independent way; e.g., how computePredInstDiscount() and sinkScalarOperands() work to expand the scope of scalarized instructions according to the cumulative cost discount of potentially scalarized instruction chains. Unless there's a good reason for it to be target specific(?)
>
> The only target-specific part I am thinking about is which instructions will later be expanded during *isel*.
>
> > My question back to you is why Scalars is not good enough for your purpose. You get different "scalarlization" answer in collectLoopScalars() and collectTargetScalarized()?
>
> My understanding is that currently the LoopVectorizer notion of a scalarized instruction refers to an *LLVM I/R* scalarized instruction. In other words, which instructions it will itself produce scalarized. These are the instructions contained in Scalars[VF].


I think you are either 1) arm-twisting the vectorizer to emit vector code which you know will be scalar or 2) arm-twisting vectorizer's cost model to believe what you are emitting as "vector" to be really scalar. I certainly do not see the reason why "you have to" do that, because letting vectorizer emit scalar IR instructions in those cases should be "equivalent". So, why "do you WANT to" do that? IR going out of vectorizer may be more compact, but what that'll accomplish is cheating all downstream optimizers and their cost models.

It seems to me that what you are trying to do here is bringing "packed scalar" notion into LLVM IR --- i.e., part of my IR uses vector data type but it's really just a compact form of VF-times scalar operation. I suggest bringing this to wider RFC discussion with the rest of the community ---- but I'm sure one of the questions people will ask would be "why?".


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

https://reviews.llvm.org/D53865





More information about the llvm-commits mailing list