[LLVMdev] LLVM ARM VMLA instruction

[Kay Tiong Khoo]

Just to clarify: gcc 4.8.1 generates that fma at -O2; no FP relaxation or
other flags specified.


On Wed, Dec 18, 2013 at 6:02 PM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote:

> 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/6b64b9cd/attachment.html>