<div dir="ltr"><div><div>Hi Samuel,<br><br></div>I don't think clang follows what gcc does regarding FMA - at least by default. I don't have a PPC compiler to test with, but for x86-64 using clang trunk and gcc 4.9:<br>
<br>$ cat fma.c <br>float foo(float x, float y, float z) { return x * y + z; }<br><br>$ ./clang -march=core-avx2 -O2 -S fma.c -o - | grep ss<br>    vmulss    %xmm1, %xmm0, %xmm0<br>    vaddss    %xmm2, %xmm0, %xmm0<br><br>
$ ./gcc -march=core-avx2 -O2 -S fma.c -o - | grep ss<br>    vfmadd132ss    %xmm1, %xmm2, %xmm0<br><br>----------------------------------------------------------------------<br><br></div><div>This was brought up in Dec 2013 on this list:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-December/068868.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-December/068868.html</a><br></div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">
I don't see an answer as to whether this is a bug for all the other compilers, a deficiency in clang's default settings, or just an implementation choice.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
Sanjay<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 31, 2014 at 9:50 AM, Samuel F Antao <span dir="ltr"><<a href="mailto:sfantao@us.ibm.com" target="_blank">sfantao@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p><font face="sans-serif">Hi Tim,</font><br>
<br>
<font face="sans-serif">Thanks for the thorough explanation. It makes perfect sense.</font><br>
<br>
<font face="sans-serif">I was not aware fast-math is supposed to prevent more precision being used than what is in the standard.</font><br>
<br>
<font face="sans-serif">I came across this issue while looking into the output or different compilers. XL and Microsoft compiler seem</font><br>
<font face="sans-serif">to have that turned on by default. But I assume that clang follows what gcc does, and have that turned off.</font><br>
<br>
<font face="sans-serif">Thanks again,</font><br>
<font face="sans-serif">Samuel</font><br>
<br>
<tt><font>Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote on 07/31/2014 09:54:55 AM:<br>
<br>
> From: Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></font></tt><br>
<tt><font>> To: Samuel F Antao/Watson/IBM@IBMUS</font></tt><br>
<tt><font>> Cc: "<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>" <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>>, Olivier H <br>
> Sallenave/Watson/IBM@IBMUS</font></tt><br>
<tt><font>> Date: 07/31/2014 09:55 AM</font></tt><br>
<tt><font>> Subject: Re: [LLVMdev] FPOpFusion = Fast and Multiply-and-add combines</font></tt></p><div><div class="h5"><br>
<tt><font>> <br>
> Hi Samuel,<br>
> <br>
> On 30 July 2014 22:37, Samuel F Antao <<a href="mailto:sfantao@us.ibm.com" target="_blank">sfantao@us.ibm.com</a>> wrote:<br>
> > In the DAGCombiner, during the combination of mul and add/subtract into<br>
> > multiply-and-add/subtract, this option is expected to be Fast in order to<br>
> > enable the combine. This means, that by default no multiply-and-add opcodes<br>
> > are going to be generated. If I understand it correctly, this is undesirable<br>
> > given that multiply-and-add for targets like PPC (I am not sure about all<br>
> > the other targets) does not pose any rounding problem and it can even be<br>
> > more accurate than performing the two operations separately.<br>
> <br>
> That extra precision is actually what we're being very careful to<br>
> avoid unless specifically told we're allowed. It can be just as<br>
> harmful to carefully written floating-point code as dropping precision<br>
> would be.<br>
> <br>
> > Also, in TargetOptions.h I read:<br>
> ><br>
> > Standard, // Only allow fusion of 'blessed' ops (currently just fmuladd)<br>
> ><br>
> > which made me suspect that the check against Fast in the DAGCombiner is not<br>
> > correct.<br>
> <br>
> I think it's OK. In the IR there are 3 different ways to express mul + add:<br>
> <br>
> 1. fmul + fadd. This must not be fused into a single step without<br>
> intermediate rounding (unless we're in Fast mode).<br>
> 2. call @llvm.fmuladd. This *may* be fused or not, depending on<br>
> profitability (unless we're in Strict mode, in which case it's<br>
> separate).<br>
> 3. call @llvm.fma. This must not be split into two operations (unless<br>
> we're in Fast mode).<br>
> <br>
> That middle one is there because C actually allows you to allow &<br>
> disallow contraction within a limited region with "#pragma STDC<br>
> FP_CONTRACT ON". So we need a way to represent the idea that it's not<br>
> usually OK to fuse them (i.e. not Fast mode), but this particular one<br>
> actually is OK.<br>
> <br>
> Cheers.<br>
> <br>
> Tim.<br>
> <br>
</font></tt></div></div><p></p></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div></div></div></div>