Shufflevector & InstCombine

[Nadav Rotem]

Hi Eli and James, 

I’d like to add that It is really difficult to predict the cost of shuffles, even with TTI.  This presentation describes the problem pretty well:

http://www.nondot.org/sabre/2012-04-02-CGOKeynote.pdf

DAGCombine needs to cleanup after legalization and perform optimizations that are target-specific (such as handling shuffles).

Thanks,
Nadav


On Aug 9, 2013, at 8:43 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Mon, Aug 5, 2013 at 1:18 PM, James Molloy <james at jamesmolloy.co.uk> wrote:
>> Hi Nadav,
>> 
>> Thanks for the quick and unambiguous response.
>> 
>> One thing - I thought the rationale of SelectionDAG was that it did
>> optimizations that were implicit in the IR - that is, all optimizations that
>> change IR should be done on the IR, and only what's left over (because of
>> IR's high level) should be done in DAGCombine.
>> 
>> Has the rationale changed here, or is it just the "least worst" place?
> 
> Well, our extremely conservative stance on instcombines for
> shufflevectors was before we had TargetTransformInfo... it's possible
> we can perform more aggressive transforms if we have cost info.  That
> said, keep in mind that for hand-written code, the author is often
> smarter than the compiler in terms of how to represent shuffles.
> 
> -Eli