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


— 
Mehdi




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