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

[Sanjay Patel via llvm-dev]

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>