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

[Ristow, Warren via llvm-dev]

Hi,

Thanks for the quick feedback.  I see your points, but I have a few questions/comments.  I'll start at the end of the previous post:

> ...
> I think these are valuable problems to solve, but you should tackle them piece by piece:
>
> 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix.
> 2) the backend is still using the global UnsafeFPMath and it should be killed.

I addressed this point (2) for the reciprocal aspect in the patch, but of course that wasn't useful without doing something about (1).

Regarding (1), over at https://reviews.llvm.org/D26708#596610, David made the same point that it should be done in Clang.  I can understand that, but I wonder whether having the concept of the 'fast' flag in the IR that implies all the other FMF makes sense?  I'm not seeing a good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture.

For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined.  Except for 'fast', each of these has a fairly specific definition of what they mean.  For example, for 'arcp':

    arcp => "Allow optimizations to use the reciprocal of an argument rather
             than perform division."

'fast' is unusual, in that it describes a fairly generic set of aggressive floating-point optimizations:

    fast => "Allow algebraically equivalent transformations that may dramatically
            change results in floating point (e.g. reassociate). This flag implies
            all the others."

Very loosely, 'fast' means "all the aggressive FP-transformations that are not controlled by one of the other 4, plus it implies all the other 4".  If for terminology, we call those additional aggressive optimizations 'aggr', then we have:

    'fast' == 'aggr' + 'nnan' + 'ninf' + 'nsz' + 'arcp'

So as I see it, if we want to disable only one of the other ones (like 'arcp', in my case), there isn't any way to express that with these IR flags defined this way.  In short, we cannot turn on all the flags besides 'arcp'.  To do that, what we want is that somehow for the Clang switches:

  '-ffast-math -fno-reciprocal-math'

to ultimately result in LLVM IR that has the following flags on in appropriate FP ops:

  'aggr' + 'nnan' + 'ninf' + 'nsz'

But I don't see a way to express 'aggr' in the IR.  We could do this, if we change the definition of the IR 'fast' flag to remove that sentence about implying all the others:

    fast => "Allow algebraically equivalent transformations that may dramatically
            change results in floating point (e.g. reassociate).

(If we do something like that, we may want to change the name from 'fast' to something else (like 'aggr'), to avoid tying it too closely to the concept of the '-ffast-math' switch.)

As an aside, I don't know if the "reassociate" example is the only other transformation that's allowed by 'fast' (I presume it isn't), but I think reassociation would be better expressed by a separate flag, which could then be controlled independently via '-f[no]-associative-math' switch.  Not having that flag exist separately in the FMF is the origin of PR27372.  But creating that flag and using it in the appropriate places would still run into these problems of 'fast' implying all the others, which would make it impossible to disable reassociation while leaving all the other FMF transformations enabled.

To ask a concrete question using the current definition of 'fast' (which includes enabling reassociation, as the LLVM IR documentation of FMF says), how can we express in the IR that reciprocal-transformations are not allowed, but reassociation is allowed?

So the bottom line is that I do see there are issues in Clang that are relevant.  But as long as 'fast' means "'aggr' plus all the other FMF transformations", I don't see how we can effectively disable a subset of those other FMF transformations (while leaving 'aggr' transformations, such as reassociation, enabled).  With that in mind, my patch took one step in having 'fast' no longer imply all the others.

Thanks,
-Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161116/fc2754a5/attachment-0001.html>