llvm dev - Dec 2013 - [LLVMdev] LLVM ARM VMLA instruction

> "-ffp-contract=fast" is needed
Correct - clang is different than gcc, icc, msvc, xlc, etc. on this. Still
haven't seen any explanation for how this is better though...

http://llvm.org/bugs/show_bug.cgi?id=17188
http://llvm.org/bugs/show_bug.cgi?id=17211


On Wed, Dec 18, 2013 at 6:02 AM, Tim Northover <t.p.northover at
gmail.com>wrote:
> > I believe that's the NEON VMLA, not the VFP one.
>
> Turns out I was misreading the assembly. I wish "vmla" and
"vfma"
> weren't so similar-looking.
>
> For Suyog that means the option "-ffp-contract=fast" is needed to
get
> vfma when needed. Sorry about the bad information earlier.
>
> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131218/b6625009/attachment.html>

> http://llvm.org/bugs/show_bug.cgi?id=17188
> http://llvm.org/bugs/show_bug.cgi?id=17211
Ah, thanks. That makes a lot more sense now.
> Correct - clang is different than gcc, icc, msvc, xlc, etc. on this. Still
> haven't seen any explanation for how this is better though...
That would be because it follows what C tells us a compiler has to do
by default but provides overrides in either direction if you know what
you're doing.

The key point is that LLVM (currently) has no notion of statement
boundaries, so it would fuse the operations in this function:

float foo(float accum, float lhs, float rhs) {
  float product = lhs * rhs;
  return accum + product;
}

This isn't allowed even under FP_CONTRACT=on (the multiply and add do
not occur within a single expression), so LLVM can't in good
conscience enable these optimisations by default.

Cheers.

Tim.

Thanks for the explanation, Tim!

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?

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?

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".


On Wed, Dec 18, 2013 at 11:17 AM, Tim Northover <t.p.northover at
gmail.com>wrote:
> > http://llvm.org/bugs/show_bug.cgi?id=17188
> > http://llvm.org/bugs/show_bug.cgi?id=17211
>
> Ah, thanks. That makes a lot more sense now.
>
> > Correct - clang is different than gcc, icc, msvc, xlc, etc. on this.
> Still
> > haven't seen any explanation for how this is better though...
>
> That would be because it follows what C tells us a compiler has to do
> by default but provides overrides in either direction if you know what
> you're doing.
>
> The key point is that LLVM (currently) has no notion of statement
> boundaries, so it would fuse the operations in this function:
>
> float foo(float accum, float lhs, float rhs) {
>   float product = lhs * rhs;
>   return accum + product;
> }
>
> This isn't allowed even under FP_CONTRACT=on (the multiply and add do
> not occur within a single expression), so LLVM can't in good
> conscience enable these optimisations by default.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131218/d9e4d25c/attachment.html>