[PATCH] Teach the DAGCombiner how to fold a OR of two shufflevector into a single shufflevector node

[Hal Finkel]

----- Original Message -----
> From: "Tim Northover" <t.p.northover at gmail.com>
> To: "Nadav Rotem" <nrotem at apple.com>
> Cc: "llvm-commits at cs.uiuc.edu for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Wednesday, March 5, 2014 1:50:49 PM
> Subject: Re: [PATCH] Teach the DAGCombiner how to fold a OR of two	shufflevector into a single shufflevector node
> 
> Hi Nadav,
> 
> > Thanks for working on this.  Lowering shuffles is really difficult
> > and we
> > have >1000 LOC in the x86 backends for lowering shuffles.  It is
> > really
> > difficult to predict which shuffles are supported and which
> > patterns result
> > in slow code. Until now LLVM was *not* to introducing new shuffle
> > patterns.
> 
> What do we count as new shuffle patterns here? I've been working on
> InstCombine recently, trying to make it more flexible about how it
> turns insertelement/extractelements into shuffles. (The limitation
> I'm
> trying to get around is that it will form any shuffle it can, but
> only
> if the input and output vector types are the same).
> 
> I'm now slightly worried that we don't want to do this even when I do
> get it working, but on the other hand the class already produced is
> hardly backend-friendly.

I think that, rightly, we've had a policy against doing this during the canonicalization phases. Introducing new shuffle masks can be done, and in many cases should be done, during the lowering phases. This can either be during the late IR phases (vectorization, CGP) or during CodeGen proper. The problem is that there is no good target-independent canonical form for these, and constructing a set of good masks from a set of bad ones is algorithmically hard.

That having been said, if the right way to implement the late IR parts of this is by refactoring to share some infrastructure with InstCombine, then I see no problem with that.

And that having been said, maybe the specifics of what you're doing could be a useful canonicalization -- you'd have to provide additional details.

 -Hal

> 
> Cheers.
> 
> Tim.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory