[llvm-dev] [cfe-dev] [RFC] FP Contract = fast?

[Hal Finkel via llvm-dev]

On 03/15/2017 12:10 PM, Adam Nemet via llvm-dev wrote:
> Relevant to this discussion is 
> http://bugs.llvm.org/show_bug.cgi?id=25721 (-ffp-contract=fast does 
> not work with LTO).  I am working on adding function attributes for 
> fp-contract=fast which should fix this.

Great!

>
> Also now that we have backend optimization remarks, I am planning to 
> report missed optimization when we can’t fuse FMAs due “fast” not 
> being on.  This will show up in the opt-viewer.  Then the user can opt 
> in either with the command-line switch or the new function attribute.

That seems useful.

Thanks again,
Hal

>
> Adam
>
>> On Mar 15, 2017, at 6:27 AM, Renato Golin via cfe-dev 
>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>> Folks,
>>
>> I've been asking around people about the state of FP contract, which
>> seems to be "on" but it's not really behaving like it, at least not as
>> I would expect:
>>
>> int foo(float a, float b, float c) { return a*b+c; }
>>
>> $ clang -target aarch64-linux-gnu -O2 -S fma.c -ffp-contract=on -o -
>> (...)
>> fmul s0, s0, s1
>> fadd s0, s0, s2
>> (...)
>>
>> $ clang -target aarch64-linux-gnu -O2 -S fma.c -ffp-contract=fast -o -
>> (...)
>> fmadd s0, s0, s1, s2
>> (...)
>>
>> I'm not sure this works in Fortran either, but defaulting to "on" when
>> (I believe) the language should allow contraction and not doing it is
>> not a good default.
>>
>> i haven't worked out what would be necessary to make it work on a
>> case-by-case basis (what kinds of fusions does C allow?) to make sure
>> we don't do all or nothing, but if we don't want to start that
>> conversation now, then I'd recommend we just turn it all the way to 11
>> (like GCC) and let people turn it off if they really mean it.
>>
>> The rationale is that:
>>
>> * Contracted operations increase precision (less rounding steps)
>> * It performs equal or faster on all architectures I know (true 
>> everywhere?)
>> * Users already expect that (certainly, GCC users do)
>> * Makes us look good on benchmarks :)
>>
>> A recent SPEC2k6 comparison Linaro did for AArch64, enabling
>> -ffp-contract=fast took the edge of GCC in a number of cases and in
>> some of them made them comparable in performance. So, any reasons not
>> to?
>>
>> If we go with it, we need to first finish the job that Sebastian was
>> dong on the test-suite, then just turn it on by default. A second
>> stage would be to add tests/benchmarks that explicitly test FP
>> precision, so that we have some extra guarantee that we're doing the
>> right thing.
>>
>> Opinions?
>>
>> cheers,
>> --renato
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/9754e1d0/attachment.html>