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

If we take this argument to its end: any one of those relaxed FP settings
*guarantees* that we cannot ensure that the result will be the same between
two versions of clang. Therefore, we can no-op all of them, and greatly
simplify the optimizer.

I know that's not what you're advocating, but the suggestion that we
remove
'arcp' is the first step on that path. We can't do that. We must
make a
good faith effort to support these flags.

On Thu, Nov 17, 2016 at 9:31 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> On Nov 17, 2016, at 8:30 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
>
> 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> 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/
>
>
> 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
>
> -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.
>
>
> The last part should read “even when disabling reciprocal”
>
> —
> Mehdi
>
>
>
>
> —
> Mehdi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/bc9a7001/attachment.html>

> On Nov 17, 2016, at 9:00 AM, Sanjay Patel <spatel at rotateright.com>
wrote:
> 
> If we take this argument to its end: any one of those relaxed FP settings
*guarantees* that we cannot ensure that the result will be the same between two
versions of clang. Therefore, we can no-op all of them, and greatly simplify the
optimizer.
I don’t understand the logic here.

> I know that's not what you're advocating, but the suggestion that
we remove 'arcp' is the first step on that path. We can't do that.
We must make a good faith effort to support these flags.
I disagree, we can do it if don’t see any perceived value.
Saying “gcc has this option” does not mean we have to mimic its behavior if it
does not make sense to us.

Note: *I* am not in favor of removing arcp, even though I don’t believe Warren’s
use-case is really compelling.
— 
Mehdi

> 
> On Thu, Nov 17, 2016 at 9:31 AM, Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
> 
>> On Nov 17, 2016, at 8:30 AM, Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
>> 
>>> 
>>> On Nov 17, 2016, at 8:03 AM, Sanjay Patel <spatel at
rotateright.com <mailto: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.
> 
> The last part should read “even when disabling reciprocal”
> 
> — 
> Mehdi
> 
> 
>> 
>> 
>> — 
>> Mehdi
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/1e806742/attachment.html>

> On Nov 17, 2016, at 9:10 AM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>> 
>> On Nov 17, 2016, at 9:00 AM, Sanjay Patel <spatel at rotateright.com
<mailto:spatel at rotateright.com>> wrote:
>> 
>> If we take this argument to its end: any one of those relaxed FP
settings *guarantees* that we cannot ensure that the result will be the same
between two versions of clang. Therefore, we can no-op all of them, and greatly
simplify the optimizer.
> 
> I don’t understand the logic here.
I understand now, and I think I answered below: yes we “can" no-op all of
them, and no we don’t do it because they are valuable, because we find them
useful, not because GCC expose them on its command line.

— 
Mehdi

> 
> 
>> I know that's not what you're advocating, but the suggestion
that we remove 'arcp' is the first step on that path. We can't do
that. We must make a good faith effort to support these flags.
> 
> I disagree, we can do it if don’t see any perceived value.
> Saying “gcc has this option” does not mean we have to mimic its behavior if
it does not make sense to us.
> 
> Note: *I* am not in favor of removing arcp, even though I don’t believe
Warren’s use-case is really compelling.
> — 
> Mehdi
> 
> 
>> 
>> On Thu, Nov 17, 2016 at 9:31 AM, Mehdi Amini <mehdi.amini at
apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> 
>>> On Nov 17, 2016, at 8:30 AM, Mehdi Amini <mehdi.amini at
apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>> 
>>>> 
>>>> On Nov 17, 2016, at 8:03 AM, Sanjay Patel <spatel at
rotateright.com <mailto: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.
>> 
>> The last part should read “even when disabling reciprocal”
>> 
>> — 
>> Mehdi
>> 
>> 
>>> 
>>> 
>>> — 
>>> Mehdi
>> 
>> 
> 
> _______________________________________________
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/7d15cf28/attachment.html>