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

[Nicolai Hähnle via llvm-dev]

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