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

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>

> On Mar 15, 2017, at 10:13 AM, Hal Finkel via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 
> 
> 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
<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!
> 
A function attribute would be a strict improvement over today: LLVM can’t do
contraction today. But actually I’m not sure if it is the long term right
choice: attributes don’t combine well with inlining for instance. You mentioned
FMF earlier, why don’t we have a FMF to allow contraction?

Also, IIUC, the function attribute as well as a FMF wouldn’t apply to the “ON”
setting but only to the “FAST” mode (no way to distinguish source level
statement in llvm IR).

— 
Mehdi




>> 
>> 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
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> 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
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/ff57719f/attachment.html>

> On Mar 15, 2017, at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
> 
>> On Mar 15, 2017, at 10:13 AM, Hal Finkel via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> 
>> 
>> 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
<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!
>> 
> 
> A function attribute would be a strict improvement over today: LLVM can’t
do contraction today. But actually I’m not sure if it is the long term right
choice: attributes don’t combine well with inlining for instance. You mentioned
FMF earlier, why don’t we have a FMF to allow contraction?
OK, I thought that the prerequisite for that was a fast-math pragma which I
don’t think is something we have (I want to be able to specify contract=fast on
smaller granularity than module).  But now that I think more about, we should be
able to turn a user function attribute into FMF in the front-end which is the
most flexible.
> 
> Also, IIUC, the function attribute as well as a FMF wouldn’t apply to the
“ON” setting but only to the “FAST” mode (no way to distinguish source level
statement in llvm IR).
Yes.

Adam
> 
> — 
> Mehdi
> 
> 
> 
> 
> 
>>> 
>>> 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
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> 
>> -- 
>> Hal Finkel
>> Lead, Compiler Technology and Programming Languages
>> Leadership Computing Facility
>> Argonne National Laboratory
>> _______________________________________________
>> 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
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/24631226/attachment.html>