[llvm] r182499 - This is an update to a previous commit (r181216).

Jean-Luc Duprat jduprat at apple.com
Wed May 22 13:29:46 PDT 2013


I agree that the select is a more natural canonical form, and I was initially convinced that this was the way to go.
But none of the platforms with an FMA actually benefit from seeing this in the select form; in general, floating-point multiplies are likely better optimized than floating point selects anyways.

It seems that we'd have to fix each and every platform to undo this particular instcombine, so it is probably better to just do it as a target specific optimization where it truly is the better choice.  This just seems to be the better compromise here.


JL


On May 22, 2013, at 11:48 , Rafael Espíndola <rafael.espindola at gmail.com> wrote:

> On 22 May 2013 14:29, Jean-Luc Duprat <jduprat at apple.com> wrote:
>> Author: jduprat
>> Date: Wed May 22 13:29:31 2013
>> New Revision: 182499
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=182499&view=rev
>> Log:
>> This is an update to a previous commit (r181216).
>> 
>> The earlier change list introduced the following inst combines:
>> B * (uitofp i1 C) —> select C, B, 0
>> A * (1 - uitofp i1 C) —> select C, 0, A
>> select C, 0, B + select C, A, 0 —> select C, A, B
>> 
>> Together these 3 changes would simplify :
>> A * (1 - uitofp i1 C) + B * uitofp i1 C
>> down to :
>> select C, B, A
>> 
>> In practice we found that the first two substitutions can have a
>> negative effect on performance, because they reduce opportunities to
>> use FMA contractions; between the two options FMAs are often the
>> better choice.  This change list amends the previous one to enable
>> just these inst combines:
> 
> Why not codegen those selects to FMA instead? The select looks like a
> more natural canonical form.
> 
> Cheers,
> Rafael





More information about the llvm-commits mailing list