[llvm-commits] Please review: FMA3 instructions set

[Demikhovsky, Elena]

I can switch off FMA auto-detection meanwhile to proceed with check-in.
So FMA will be enabled under "+fma3" only.

- Elena

-----Original Message-----
From: Evan Cheng [mailto:evan.cheng at apple.com] 
Sent: Wednesday, May 23, 2012 17:22
To: Stephen Canon
Cc: Demikhovsky, Elena; llvm-commits at cs.uiuc.edu LLVM; Lang Hames
Subject: Re: [llvm-commits] Please review: FMA3 instructions set

cc'ing Lang. He is going to make the Clang change to form llvm.fmuladd intrinsics at frontend codegen time (from mul / add within an expression). The backend can then codegen these  to fma when FP_CONTRACT is on.

Evan

On May 23, 2012, at 6:54 AM, Stephen Canon <scanon at apple.com> wrote:

> Elena --
> 
> It's not quite that simple.
> 
> Even if we make [#pragma STDC FP_CONTRACT on] the default (which we should), that licenses FMA formation only *within an expression*.  i.e.:
> 
> 	double x,y,z;
> 	double r = x*y + z; // can be contracted to fma(x,y,z)
> 	double p = x*y;
> 	double q = p + z; // cannot be contracted to fma(x,y,z), even if p is never used elsewhere.
> 
> We can (and should!) have a relaxed-fp flag that licenses FMA formation wherever the LLVM judges it to be a performance win, but that mode will not comply with C floating-point semantics (nor with those of several other languages).
> 
> - Steve
> 
> On May 23, 2012, at 3:13 AM, "Demikhovsky, Elena" <elena.demikhovsky at intel.com> wrote:
> 
>> By default, FMA should be switched on. The "#pragma FP_COTRACT off "deprecates FMA. But there is no direct link in the LLVM sources between the pragma and code generation options.
>> 
>> - Elena
>> 
>> -----Original Message-----
>> From: Anton Korobeynikov [mailto:anton at korobeynikov.info] 
>> Sent: Tuesday, May 22, 2012 19:53
>> To: Stephen Canon
>> Cc: Demikhovsky, Elena; llvm-commits at cs.uiuc.edu
>> Subject: Re: [llvm-commits] Please review: FMA3 instructions set
>> 
>>> Do I understand correctly that this patch lowers fadd + fmul to fma by default?  We want it to be easy for LLVM to generate fma when it is beneficial to performance, but we can't simply naively lower to it everywhere and still conform to language semantics.  Someone else can speak to what policy should be here, but at the very least we will need to have an option to block fma formation.
>> 
>> One can check how fma is implemented on ARM. In general - stuff should be guarded by NoExcessPrecision flag or something like this
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.