[PATCH] D39304: [IR] redefine 'reassoc' fast-math-flag and add 'trans' fast-math-flag

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added inline comments.


================
Comment at: docs/LangRef.rst:10498
+floating point number. When specified with the fast-math-flag 'afn', the
+result may not match a conforming libm implementation. 
 
----------------
efriedma wrote:
> hfinkel wrote:
> > This conformance language is only necessary for sqrt. For the other functions, there is no standard for their accuracy/precision. You might say that with 'afn' the result may not match what would have been returned by the system's libm implementation.
> We probably want different language here than for the transcendental functions; libm sqrt() is precisely the IEEE754 squareRoot().
True. On the other hand, the system's libm sqrt should be IEEE compliant, so saying that this differs from the libm result covers that (and also covers other cases, such as PPC long double, which aren't IEEE).


================
Comment at: docs/LangRef.rst:10866
 This function returns the same values as the libm ``fma`` functions
-would, and does not set errno.
+would, and does not set errno. When specified with the fast-math-flag 'afn', 
+the result may not match the system's libm implementation.
----------------
efriedma wrote:
> hfinkel wrote:
> > I don't expect that afn would affect fma. I recommend removing the statement here. It might be true that fma is computed differently under -ffast-math because of denormal handling, but that applies to everything. The same is true of the conversion functions below (floor, rint, etc.). maxnum/minnum too.
> We might want to transform fma(a,b,c) to a*b+c in fast-math mode on targets which don't have a native fma instruction?  Not sure if that makes sense.
Good point. This would be relatively easy to implement as well:

  afn fma(a, b, c) -> [afn] fmuladd(a, b, c)

fmuladd lowers either to an fma, or not, depending on target preferences.



================
Comment at: docs/LangRef.rst:10574
+conditions in the same way. When specified with the fast-math-flag 'afn', 
+the result may not match the system's libm implementation.
 
----------------
efriedma wrote:
> This language might give the wrong idea.  Even without 'afn', the result may not match the target's libm: we constant-fold using a different implementation.  The part to call out is that we might substitute an implementation which is less accurate.
> we constant-fold using a different implementation.

Which, indeed, might be less accurate -- just hopefully not by much ;)

I realize that having these notes on the intrinsics seems like it could be helpful, but I'm leaning toward recommending that we don't have them at all.


https://reviews.llvm.org/D39304