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

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

On 03/15/2017 01:47 PM, Adam Nemet wrote:
>
>> On Mar 15, 2017, at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com 
>> <mailto: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 (-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.
I agree, a FMF is the way to go and we can then control it with the 
pragma. We can use the STDC FP_CONTRACT pragma for contraction; I also 
think that having a "fast math" pragma is also a good idea (the fact 
that we can currently only specify fast-math settings on a 
translation-unit level is somewhat problematic).
>
>>
>> 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).
Right. We still have the existing fmuladd intrinsic method for dealing 
with the "ON" setting.
>
> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> 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
>>
>
-- 
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/3f6c99cc/attachment.html>

> On Mar 15, 2017, at 2:00 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> 
> On 03/15/2017 01:47 PM, Adam Nemet wrote:
>> 
>>> On Mar 15, 2017, at 11:36 AM, Mehdi Amini <mehdi.amini at
apple.com <mailto: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.
> 
> I agree, a FMF is the way to go and we can then control it with the pragma.
We can use the STDC FP_CONTRACT pragma for contraction;
Just to confirm, do you mean to introduce a “fast” option to the pragma, e.g.:

#pragma STDC FP_CONTRACT FAST

Thanks,
Adam
> I also think that having a "fast math" pragma is also a good idea
(the fact that we can currently only specify fast-math settings on a
translation-unit level is somewhat problematic).
> 
>> 
>>> 
>>> 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).
> 
> Right. We still have the existing fmuladd intrinsic method for dealing with
the "ON" setting.
> 
>> 
>> 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>
>>> 
>> 
> 
> -- 
> 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/c413417c/attachment.html>