On Jun 5, 2012, at 1:08 PM, Chandler Carruth <[email protected]> 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 <[email protected]> wrote:
> On May 31, 2012, at 10:40 PM, John McCall <[email protected]> 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).

- Steve
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to