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

Thu Nov 17 09:10:52 PST 2016

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