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

[Mehdi Amini via llvm-dev]

> On Nov 17, 2016, at 12:51 AM, Ristow, Warren <warren.ristow at sony.com> 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.

My point was that supporting these switch are not a guarantee for a fast-math user that his code will work, even the same command line flags is enough to make it work with GCC.
If you are providing these and saying that we are “compatible” with GCC to your users, in the sense that their code will continue to work, that seems incorrect to me.
What are you gonna answer them when they’ll use such flag but it won’t be enough for their code to work with clang even though it works with GCC? (Possibly because reassociation mess up another part of the code that GCC didn’t mess, because of different inlining decisions for instance).


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

The multiple customers may want a pony, we’re not gonna try to give them one just because they ask. I’d push back on such customer request for the reason I gave earlier. 
If what they want does not make sense or we can’t provide the guarantee they really want, it is also our job to *not* provide them this and guide them toward an alternative model that is more controlled, understood, and solve the underlying problem they have.
As an example of “pony” request: I had a customer that wanted their floating-point “conformance test” to pass with fast-math:  "float test_div(float a, float b) { return a/b; }” ; they didn’t see any reason why the compiler would do anything wrong on such a simple test (except that the HW didn’t have a division instruction…).

That being said, even though I’m not convinced by your “pony” use case, I don’t see any reason to not preserve the arcp flag in the IR at this point (Nicolai may disagree, let see his opinion), and it still make sense to me to try to change the *fast* flag to “reassociation” (or similar) in the IR (provided that we don’t find clients of the API that want “more” than reassociation + a combination of the other flags).

This should be enough to provide these command line switches at the clang level, and this should avoid you (Sony) to have to maintain any out-of-tree support for this.

Hope this clarify where I see the direction going, and even if you don’t agree with my reasoning, the conclusion should be satisfactory on your side :)


— 
Mehdi


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