patch: make instcombine remove shuffles by reordering vector elements

Nick Lewycky nicholas at mxc.ca
Sat May 4 07:21:13 PDT 2013


Nadav Rotem wrote:
> Hi Nick,
>
> Thanks for working on this. In this patch you are creating new shuffles
> with new masks. We discussed this issue on the mailing list last week.
> The current design decision in LLVM is that we don't generate new
> shuffle nodes because of two reasons: cost model and optimization
> issues. We can't predict if the cost of the new shuffle is lower than
> the existing one. New shuffles can potentially be very difficult to
> lower. For example, AVX forbids cross-lane shuffles. We also discussed
> why merging shuffles can't be reversed in the codegen. Are you trying to
> solve a particular problem with this patch ? Maybe there are other ways
> to solve this without introducing new shuffles.

Ah, sorry. I'm still catching up on email and haven't made it to this 
discussion yet.

> The LoopVectorizer only generates two kinds of shuffles: Reverse and
> Broadcast, which have target hooks for cost estimation in TTI. So I am
> not expecting this patch to affect it. The SLP Vectorizer does not
> generate shuffles at the moment. But the plan is to shuffle only loads
> (this is also what GCC does AFAIK), so I don't think that it would
> benefit the SLP Vectorizer.

I don't still have the motivating C++ source. A while ago when looking 
at .ll files produced with the loop vectorizer enabled, I noticed 
redundant shuffles and made a note to myself to write this optimization.

The good news is that when this transform fires it always deletes one 
shuffle. We can still run the transform only to reorder insertelement 
indices (make it return false for all shufflevectors in 
CanEvaluateShuffled). If the backend is capable of lowering a bad 
shuffle to multiple shuffles instead of scalarizing then we can conclude 
that this patch at worst moves shuffles around. If the backend doesn't 
do that but we have some way of determining whether a shuffle is good or 
bad, we can use that to ensure we don't fold two good shuffles into a 
single bad one.

Nick



More information about the llvm-commits mailing list