[llvm-commits] [cfe-commits] [PATCH] Add llvm.fmuladd intrinsic.

[Chandler Carruth]

On Tue, Jun 5, 2012 at 1:15 PM, Stephen Canon <scanon at apple.com> wrote:

> On Jun 5, 2012, at 1:08 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> Hey Lang,
>
> Sorry to jump in late, but was catching on up email and finally read
> through this thread. This is the exchange that caught my interest:
>
> On Fri, Jun 1, 2012 at 4:50 AM, Stephen Canon <scanon at apple.com> wrote:
>
>> On May 31, 2012, at 10:40 PM, John McCall <rjmccall at apple.com> wrote:
>>
>> > On May 31, 2012, at 7:22 PM, Lang Hames wrote:
>> >> Thanks for the suggestion Matthieu. I spoke to Doug and he recommended
>> using attributes rather than a FunctionDecl bit to represent the
>> fp_contract state.
>> >
>> > Hmm.  I had suggested a bit on FunctionDecl on the assumption that this
>> would often be controlled globally, maybe by using a flag to control the
>> default or by activating a #pragma before including all the headers.
>>  Actually, I could even imagine a target (maybe a GPU target?) even
>> opting-in to this behavior by default.  If we're going to use an Attr, we
>> need to make sure it doesn't get added unless the current #pragma state is
>> different from the global default;  we really don't want to be allocating
>> an attribute for every function definition in the translation unit.
>>
>> We want FP_CONTRACT ON to be the default for all targets.  It's also
>> worth noting that it's critical that we support setting the pragma to OFF,
>> but in practice this will be exceedingly rare (almost certainly less than
>> 1% of sources, and probably far less than that).
>>
>
> Based on this comment, I'm really not keen on the current representation,
> but maybe I've mis-understood it, so I'll ask questions first:
>
> The 'fmuladd' intrinsic is used to whitelist specific operations for fused
> multiply+add handling, correct?
>
>
> Correct.
>
> If so, and if Stephen's stance is correct (I certainly agree with it!)
> that this should be allowed for the vast majority of code, that means that
> almost every fmul and fadd in the current IR should be a candidate for
> fusing?
>
>
> Only those that originate from a common source-language *expression*.
>  Your examples should not be fused because the multiply and add are in two
> separate expressions (which is why we need FE involvement; that information
> isn't available later).
>

Ok, now I'm extra confused. Thanks for replying, hopefully you can help me
understand better.

Why would it not be OK to fuse multiplies and adds that occur in two
source-language expressions? I have some vague memory of Fortran having
lots of special rules about within-expression semantics versus semantics
across expressions, but C++ has no such constraints to my knowledge, nor
would it want them.

Having these types of artificial source-representation restrictions on
semantics in C++ undermines specific language constructs like overloaded
operators and transparent "wrapper" classes.

And I'm still sold on your statement that very little code actually cares
about avoiding fusing of operations -- we should be enabling *more* fusion,
not restricting it, in the common case... right?

Again, thanks for your patience. =]
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120605/ec88cc12/attachment.html>