llvm dev - Nov 2016 - RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags

On 17.11.2016 09:51, Ristow, Warren wrote:
> Those are all good points.  Your reassociation point in the context of
> inlining is particularly interesting.
>
>
>
> FWIW, we also have a case where a customer wants
'-fno-associative-math'
> to suppress reassociation under '-ffastmath'.  It would take me a
while
> to find the specifics of the issue, but it was (if my memory is right)
> more of a real use-case.  (That is to say, the code that was
"failing"
> due to reassociation didn't have an obvious fix like the reciprocal
> situation, here, other than to turn off fast-math.)  In fact, the
> request to suppress reassociation was the motivation for creating
> PR27372 in the first place (which eventually fed into this thread).  I
> have to say that on the reassociation point, my concern is that to
> really suppress that, we will have to suppress so much, that there will
> hardly be any point in using -ffast-math.
>
>
>
> I'd say your comments here are very similar to what Nicolai said in
> another subthread of this discussion:
>
>
>
>>> I'd be really curious to know if there is anybody who really
needs arcp
>
>>> without fp-contract=fast or vice versa, or who needs both of these
but
>
>>> not the X*log2(0.5*Y) transform you mentioned, and so on.[1]
>
>>> ...
>
>>> [1] One case I _can_ think of (and which may have been a reason for
the
>
>>> proliferation of flags in the first place) is somebody who enables
fast
>
>>> math, but then doesn't want their results to change when they
update the
>
>>> compiler and get a new set of optimizations. But IMO that's a
use case
>
>>> that should be explicitly rejected.
>
>
>
> I think those are all really good points, and an argument can be made
> that when -ffast-math gives you results you don't want, then you just
> have to turn it off.  Essentially, the user can't "have his cake
and eat
> it too".
>
>
>
> All that said, I think we (the company I work for, Sony) will have to
> implement support for these switches.  It comes down to GCC has these
> switches (e.g., -fno-reciprocal-math and -fno-associative-math), and
> they do suppress the transformations for our customers.  They switch to
> Clang/LLVM, they use the same switches, and it doesn't
"work".  So as a
> practical matter, I think we will support them.  Whether the LLVM
> community in general feels that that's required, is another question.
> Until for your recent comments here, and Nicolai's comments above, I
> would have thought the answer was clearly yes.  But maybe that's not
the
> case.
>
>
>
> In summary, irrespective of any (subjective?) assessment of how
> legitimate a particular use-case is, do we want switches like:
>
>
>
>     -ffast-math -fno-reciprocal-math
>
>      -ffast-math -fno-associative-math
>
>
>
> to work?
>
>
>
> For me, the answer is yes, because I have multiple customers that tell
> me they really want to leave -ffast-math on, but they want to be able to
> disable these sub-categories.  I've been approaching this under the
> assumption that the answer is yes for the Clang/LLVM community in general.
I feel your pain, but I'm not convinced yet that this is really the 
right approach.

It sounds like the customers (a) want fast-math in general but (b) have 
some specific parts of the code where it breaks things. What about 
having them disable fast-math on a more fine-grained scope, e.g. via 
something like an __attribute__(no_fast_math) function attribute at the 
C++ source level?

Then the problematic piece of code might be slower (since all of 
fast-math is disabled), but the rest of the code would likely be faster 
(since it benefits from all of fast-math instead of just a subset).

Cheers,
Nicolai

On Thu, Nov 17, 2016 at 2:31 AM, Nicolai Hähnle via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 17.11.2016 09:51, Ristow, Warren wrote:
>
>> Those are all good points.  Your reassociation point in the context of
>> inlining is particularly interesting.
>>
>>
>>
>> FWIW, we also have a case where a customer wants
'-fno-associative-math'
>> to suppress reassociation under '-ffastmath'.  It would take me
a while
>> to find the specifics of the issue, but it was (if my memory is right)
>> more of a real use-case.  (That is to say, the code that was
"failing"
>> due to reassociation didn't have an obvious fix like the reciprocal
>> situation, here, other than to turn off fast-math.)  In fact, the
>> request to suppress reassociation was the motivation for creating
>> PR27372 in the first place (which eventually fed into this thread).  I
>> have to say that on the reassociation point, my concern is that to
>> really suppress that, we will have to suppress so much, that there will
>> hardly be any point in using -ffast-math.
>>
>>
>>
>> I'd say your comments here are very similar to what Nicolai said in
>> another subthread of this discussion:
>>
>>
>>
>> I'd be really curious to know if there is anybody who really needs
arcp
>>>>
>>>
>> without fp-contract=fast or vice versa, or who needs both of these but
>>>>
>>>
>> not the X*log2(0.5*Y) transform you mentioned, and so on.[1]
>>>>
>>>
>> ...
>>>>
>>>
>> [1] One case I _can_ think of (and which may have been a reason for the
>>>>
>>>
>> proliferation of flags in the first place) is somebody who enables fast
>>>>
>>>
>> math, but then doesn't want their results to change when they
update the
>>>>
>>>
>> compiler and get a new set of optimizations. But IMO that's a use
case
>>>>
>>>
>> that should be explicitly rejected.
>>>>
>>>
>>
>>
>> I think those are all really good points, and an argument can be made
>> that when -ffast-math gives you results you don't want, then you
just
>> have to turn it off.  Essentially, the user can't "have his
cake and eat
>> it too".
>>
>>
>>
>> All that said, I think we (the company I work for, Sony) will have to
>> implement support for these switches.  It comes down to GCC has these
>> switches (e.g., -fno-reciprocal-math and -fno-associative-math), and
>> they do suppress the transformations for our customers.  They switch to
>> Clang/LLVM, they use the same switches, and it doesn't
"work".  So as a
>> practical matter, I think we will support them.  Whether the LLVM
>> community in general feels that that's required, is another
question.
>> Until for your recent comments here, and Nicolai's comments above,
I
>> would have thought the answer was clearly yes.  But maybe that's
not the
>> case.
>>
>>
>>
>> In summary, irrespective of any (subjective?) assessment of how
>> legitimate a particular use-case is, do we want switches like:
>>
>>
>>
>>     -ffast-math -fno-reciprocal-math
>>
>>      -ffast-math -fno-associative-math
>>
>>
>>
>> to work?
>>
>>
>>
>> For me, the answer is yes, because I have multiple customers that tell
>> me they really want to leave -ffast-math on, but they want to be able
to
>> disable these sub-categories.  I've been approaching this under the
>> assumption that the answer is yes for the Clang/LLVM community in
general.
>>
>
> I feel your pain, but I'm not convinced yet that this is really the
right
> approach.
>
> It sounds like the customers (a) want fast-math in general but (b) have
> some specific parts of the code where it breaks things. What about having
> them disable fast-math on a more fine-grained scope, e.g. via something
> like an __attribute__(no_fast_math) function attribute at the C++ source
> level?
>
> Then the problematic piece of code might be slower (since all of fast-math
> is disabled), but the rest of the code would likely be faster (since it
> benefits from all of fast-math instead of just a subset).
>
This is suggesting source code changes to customers that are switching
compilers, but (as Warren hinted at) one of the stated goals of clang is
GCC compatibility:
http://clang.llvm.org/

If that's still true, it means (barring anything that we explicitly
document and choose not to support), we should support GCC's FP options:
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options

-ffp-contract=style
-ffast-math
-fno-math-errno
-funsafe-math-optimizations
-fassociative-math
-freciprocal-math
-ffinite-math-only
-fno-signed-zeros
-fno-trapping-math
-frounding-math
-fsignaling-nans
-fsingle-precision-constant

etc, and the relevant negations of these options. We can't predict how
customers will choose to chain these together, so I think the LLVM
optimizer and backend designs should accommodate all possibilities derived
from those clang flags. This includes (because I've seen this requested)
using relaxed FP modes and simultaneously enabling some subset of FP
exceptions. (I know it sounds crazy... :) )
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/a3260237/attachment.html>

> On Nov 17, 2016, at 8:03 AM, Sanjay Patel <spatel at rotateright.com>
wrote:
> 
> On Thu, Nov 17, 2016 at 2:31 AM, Nicolai Hähnle via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> On 17.11.2016 09:51, Ristow, Warren wrote:
> Those are all good points.  Your reassociation point in the context of
> inlining is particularly interesting.
> 
> 
> 
> FWIW, we also have a case where a customer wants
'-fno-associative-math'
> to suppress reassociation under '-ffastmath'.  It would take me a
while
> to find the specifics of the issue, but it was (if my memory is right)
> more of a real use-case.  (That is to say, the code that was
"failing"
> due to reassociation didn't have an obvious fix like the reciprocal
> situation, here, other than to turn off fast-math.)  In fact, the
> request to suppress reassociation was the motivation for creating
> PR27372 in the first place (which eventually fed into this thread).  I
> have to say that on the reassociation point, my concern is that to
> really suppress that, we will have to suppress so much, that there will
> hardly be any point in using -ffast-math.
> 
> 
> 
> I'd say your comments here are very similar to what Nicolai said in
> another subthread of this discussion:
> 
> 
> 
> I'd be really curious to know if there is anybody who really needs arcp
> 
> without fp-contract=fast or vice versa, or who needs both of these but
> 
> not the X*log2(0.5*Y) transform you mentioned, and so on.[1]
> 
> ...
> 
> [1] One case I _can_ think of (and which may have been a reason for the
> 
> proliferation of flags in the first place) is somebody who enables fast
> 
> math, but then doesn't want their results to change when they update
the
> 
> compiler and get a new set of optimizations. But IMO that's a use case
> 
> that should be explicitly rejected.
> 
> 
> 
> I think those are all really good points, and an argument can be made
> that when -ffast-math gives you results you don't want, then you just
> have to turn it off.  Essentially, the user can't "have his cake
and eat
> it too".
> 
> 
> 
> All that said, I think we (the company I work for, Sony) will have to
> implement support for these switches.  It comes down to GCC has these
> switches (e.g., -fno-reciprocal-math and -fno-associative-math), and
> they do suppress the transformations for our customers.  They switch to
> Clang/LLVM, they use the same switches, and it doesn't
"work".  So as a
> practical matter, I think we will support them.  Whether the LLVM
> community in general feels that that's required, is another question.
> Until for your recent comments here, and Nicolai's comments above, I
> would have thought the answer was clearly yes.  But maybe that's not
the
> case.
> 
> 
> 
> In summary, irrespective of any (subjective?) assessment of how
> legitimate a particular use-case is, do we want switches like:
> 
> 
> 
>     -ffast-math -fno-reciprocal-math
> 
>      -ffast-math -fno-associative-math
> 
> 
> 
> to work?
> 
> 
> 
> For me, the answer is yes, because I have multiple customers that tell
> me they really want to leave -ffast-math on, but they want to be able to
> disable these sub-categories.  I've been approaching this under the
> assumption that the answer is yes for the Clang/LLVM community in general.
> 
> I feel your pain, but I'm not convinced yet that this is really the
right approach.
> 
> It sounds like the customers (a) want fast-math in general but (b) have
some specific parts of the code where it breaks things. What about having them
disable fast-math on a more fine-grained scope, e.g. via something like an
__attribute__(no_fast_math) function attribute at the C++ source level?
> 
> Then the problematic piece of code might be slower (since all of fast-math
is disabled), but the rest of the code would likely be faster (since it benefits
from all of fast-math instead of just a subset).
> 
> This is suggesting source code changes to customers that are switching
compilers, but (as Warren hinted at) one of the stated goals of clang is GCC
compatibility:
> http://clang.llvm.org/ <http://clang.llvm.org/>
We don’t aim at being bug-to-bug compatible though.
I believe we are compatible in terms of command line invocation, even if some
gcc flags are no-op in clang.

> If that's still true, it means (barring anything that we explicitly
document and choose not to support), we should support GCC's FP options:
>
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options
<https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options>
> 
> -ffp-contract=style
> -ffast-math
> -fno-math-errno
> -funsafe-math-optimizations
> -fassociative-math
> -freciprocal-math
> -ffinite-math-only
> -fno-signed-zeros
> -fno-trapping-math
> -frounding-math
> -fsignaling-nans
> -fsingle-precision-constant
> 
> etc, and the relevant negations of these options. We can't predict how
customers will choose to chain these together, so I think the LLVM optimizer and
backend designs should accommodate all possibilities derived from those clang
flags. This includes (because I've seen this requested) using relaxed FP
modes and simultaneously enabling some subset of FP exceptions. (I know it
sounds crazy... :) )
I am not convinced, because when disabling IEEE compliance we can’t even ensure
that the result will be the same between two versions of clang (indeed it won’t
in many/most real-world cases), the claim that we are “GCC compatible” has not
much value here: the code can still break when built with clang and not when
built with GCC, even when disabling fast-math.


— 
Mehdi




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/3d98c6ea/attachment.html>