[PATCH] Refactor and enhance FMA combine

Mehdi Amini mehdi.amini at apple.com
Thu Apr 2 14:25:19 PDT 2015


> On Apr 2, 2015, at 2:19 PM, Owen Anderson <resistor at mac.com> wrote:
> 
> 
>> On Apr 2, 2015, at 1:23 PM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote:
>> 
>> 
>>> On Apr 2, 2015, at 1:08 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>> 
>>> I’m not sure backend specific transform can rely on the generic LLVM combiner not to canonicalize in a way that they “don’t like”. I think they have to handle the canonical form whatever it is. 
>>> I suspect that many canonicalizations in general can go in the wrong direction in specific cases for specific targets.
>> 
>> This is true, but it’s also worthwhile to consider ramifications for targets when choosing a canonical form.  It’s generally not a good idea to pick a canonical representation that is the opposite of what every backend wants.  In this case, it might not be every backend, but it does seem like there’s a class of processors for which this might not be desirable, and it’s worth considering that when choosing which form to consider canonical.  I’m not interested in dictating the outcome of that consideration, but it’s still a consideration to be made.
> 
> Also, canonicalizing (fsub (fneg A), B) -> (fneg (fadd A, B)) is in conflict with existing canonical forms in SelectionDAG, which generally tries to move FNEG’s upwards in expression trees.

To be clear: i was not suggesting that one form was better than the other, my point was just that a particular backend cannot try to combine generic ISD node in a different way than the generic one.
And since you can have in general situation where there can be conflicting interest, a (especially out-of-tree) particular backend cannot expect that such canonicalization won’t be added.
Or, said differently,  it is not because the generic SelectionDAG does not apply a canonicalization today that it might not chose one tomorrow. If you have an out-of-tree backend and you chose to canonicalize generic ISD instead of pushing upstream to have one form adopted, you can’t complain...

— 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150402/25974dce/attachment.html>


More information about the llvm-commits mailing list