<div dir="ltr"><div><div>Hi,<br><br>One more addition to above observation :<br><br></div>LLVM :<br><br></div>cortex-a15 + vfpv4-d16 + ffast-math option WITHOUT ffp-contract=fast option also emits vfma instruction.<br><br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 19, 2013 at 1:30 PM, suyog sarda <span dir="ltr"><<a href="mailto:sardask01@gmail.com" target="_blank">sardask01@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<br><br><br>Thanks for the info. Few observations from my side :<br><br><br>LLVM :<br><br><br>cortex-a8 vfpv3 : no vmla or vfma instruction emitted<br>
<br>cortex-a8 vfpv4 : no vmla or vfma instruction emitted (This is invalid though as cortex-a8 does not have vfpv4)<br>
<br>cortex-a8 vfpv4 with ffp-contract=fast : vfma instruction emitted ( this seems a bug to me!! If cortex-a8 doesn't come with vfpv4 then vfma instructions generated will be invalid )<br><br><br>cortex-a15 vfpv4 : vmla instruction emitted (which is a NEON instruction)<br>
<br>cortex-a15 vfpv4 with ffp-contract=fast vfma instruction emitted.<br><br><br>GCC :<br><br><br>cortex-a8 vfpv3 : vmla instruction emitted<br><br>cortex-a15 vfpv4 : vfma instruction emitted <br><br><br>I agree to the point that NEON and VFP instructions shouldn't be used interchangeably. <br>
<br><br>However, if gcc emits vmla (NEON) instruction with cortex-a8 then shouldn't LLVM also emit vmla (NEON) instruction? Can someone please clarify on this point? The performance gain with vmla instruction is huge. Somewhere i read that LLVM prefers precision accuracy over performance. Is this true and hence LLVM is not emiting vmla instructions for cortex-a8?<br>
<div><br><br> </div><div class="gmail_quote"><div><div class="h5">On Thu, Dec 19, 2013 at 6:41 AM, Kay Tiong Khoo <span dir="ltr"><<a href="mailto:kkhoo@perfwizard.com" target="_blank">kkhoo@perfwizard.com</a>></span> wrote:<br>
</div></div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)" class="gmail_quote"><div><div class="h5"><div dir="ltr">Just to clarify: gcc 4.8.1 generates that fma at -O2; no FP relaxation or other flags specified.<br>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 6:02 PM, Kay Tiong Khoo <span dir="ltr"><<a href="mailto:kkhoo@perfwizard.com" target="_blank">kkhoo@perfwizard.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)" class="gmail_quote"><div dir="ltr"><div><div>Thanks for the explanation, Tim!<br>
<br></div>gcc 4.8.1 *does* generate an fma for your code example for an x86 target that supports fma. I'd bet that the HW vendors' compilers do the same, but I don't have any of those installed at the moment to test that theory. So this is a bug in those compilers? Do you know how they justify it?<br>
<br></div><div>I see section 6.5 "Expressions" in the C standard, and I can see that 6.5.8 would seem to agree with you assuming that a "floating expression" is a subset of "expression"...is there any other part of the standard that you know of that I can reference?<br>
</div><div><br></div>This is made a little weirder by the fact that gcc and clang have a 'fast' setting for fp-contract, but the C standard that I'm looking at states that it is just an "on-off-switch".<br>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 11:17 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)" class="gmail_quote">> <a href="http://llvm.org/bugs/show_bug.cgi?id=17188" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=17188</a><br>
> <a href="http://llvm.org/bugs/show_bug.cgi?id=17211" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=17211</a><br>
<br>
Ah, thanks. That makes a lot more sense now.<br>
<div><br>
> Correct - clang is different than gcc, icc, msvc, xlc, etc. on this. Still<br>
> haven't seen any explanation for how this is better though...<br>
<br>
</div>That would be because it follows what C tells us a compiler has to do<br>
by default but provides overrides in either direction if you know what<br>
you're doing.<br>
<br>
The key point is that LLVM (currently) has no notion of statement<br>
boundaries, so it would fuse the operations in this function:<br>
<div><br>
float foo(float accum, float lhs, float rhs) {<br>
</div> float product = lhs * rhs;<br>
return accum + product;<br>
}<br>
<br>
This isn't allowed even under FP_CONTRACT=on (the multiply and add do<br>
not occur within a single expression), so LLVM can't in good<br>
conscience enable these optimisations by default.<br>
<br>
Cheers.<br>
<span><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br></div></div><div class="im">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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></div></blockquote></div><br><br clear="all"><div class="im"><br>-- <br>With regards,<br>Suyog Sarda<br>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br>With regards,<br>Suyog Sarda<br>
</div>