On Tue, Jun 5, 2012 at 1:15 PM, Stephen Canon <[email protected]> wrote:
> 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). > 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
