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

[Eli Friedman via Phabricator via llvm-commits]

efriedma 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. 
 
----------------
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().


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


================
Comment at: docs/LangRef.rst:10538
+fast-math-flag 'afn', the result may not match the system's libm 
+implementation.
 
----------------
Does afn actually do anything here?  I think "unspecified sequence of rounding operations" implies it isn't exact anyway.  (And __powisf2 isn't really part of libm.)


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


https://reviews.llvm.org/D39304