Please review: Optimize vector multiply on X86

[Demikhovsky, Elena]

The same optimization was not removed from the scalar pattern of "mull". I'm just adding the same logic for the vector.
There are many such optimizations on DAG level, where we check constant  operand and simplify the operation. And I assume this is right because a new node may be generated as a result of other DAG operations.

-  Elena


-----Original Message-----
From: Benjamin Kramer [mailto:benny.kra at gmail.com] 
Sent: Sunday, June 16, 2013 17:04
To: Demikhovsky, Elena
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: Please review: Optimize vector multiply on X86


On 16.06.2013, at 15:42, "Demikhovsky, Elena" <elena.demikhovsky at intel.com> wrote:

> I just don't know what happens on other targets. If vector multiply exists and shift-left does not, it may cause scalarization.
> If you state that all targets will benefit from this, I'll put the code in under visitMUL() in DAGCombiner.cpp.

If the target doesn't support vector shifts turning it back into a multiply is trivial; I think that's what the legalizer does right now. But you can even ask the target in the combiner if the shift is legal and skip the transform if it's not.

The real question is whether we need this optimization in the backend at all, since InstCombine already does it.

- Ben

> 
> -  Elena
> 
> 
> -----Original Message-----
> From: Benjamin Kramer [mailto:benny.kra at gmail.com]
> Sent: Sunday, June 16, 2013 16:32
> To: Demikhovsky, Elena
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: Please review: Optimize vector multiply on X86
> 
> 
> On 16.06.2013, at 14:22, "Demikhovsky, Elena" <elena.demikhovsky at intel.com> wrote:
> 
>> I added an optimization that converts vector operation multiply by const to SHIFT.
>> I did this optimization for X86 only.
>> I'm wondering why it was not implemented for all targets.  I saw a proposal sent by Andrea about month ago, but it is, probably, was rejected.
> 
> Andrea's patch went into trunk as r183005. It's a mid-level optimization though (in instcombine) so you'll see the effect with opt but not with llc.
> 
> I think shl is the canonical version of a mul and I don't see why adding this as an x86-specific optimization provides any additional value. If these occur in places where instcombine can't catch them it may make sense to do it in the target-independent part of DAGCombiner.
> 
> - Ben
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for 
> the sole use of the intended recipient(s). Any review or distribution 
> by others is strictly prohibited. If you are not the intended 
> recipient, please contact the sender and delete all copies.
> 

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.