[cfe-commits] [llvm-commits] [PATCH] Add llvm.fmuladd intrinsic.
chandlerc at google.com
Tue Jun 5 13:18:47 PDT 2012
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?
> 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
> 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
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. =]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits