[LLVMdev] LLVM ARM VMLA instruction

[Kay Tiong Khoo]

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>