Hi, Sorry, but I am a little confused.
On Wed, Nov 14, 2018 at 11:28 AM Wilco Dijkstra <wilco.dijks...@arm.com> wrote: > > Hi, > > > > Indeed. After plotting the graph of both functions, it is very clear > > that this check isn't required. Sorry about that. > > It wouldn't be clear from the graph, you need to check that +0.0, -0.0, > out of range values, infinities, NaNs give the same answer before/after > your transformation. If so, then you don't need anything extra except > for unsafe-math-optimizations and no-math-errno (given errno handling > is changed). I checked it. They are all the same on x86_64: https://pastebin.com/e63FxDAy I even forced to call the glibc sinh and atanh, but use the sqrtsd instruction. But I do agree that there may be an arch that sets an errno for sinh or cosh but not for sqrt, implying in a unexpected behavior. Is the no-math-errno really necessary? > > > There can be NaNs and Infinities. For NaNs, take any input that is > > outside the [-1, 1] line. > > For Infinities, take x = -1, or x = 1. I think these must be 'honored' > > as to ensure compatibility with the original expression. > > The question is whether you get the same answer for these, not whether > you can end up with an infinity or NaN. The idea is that we optimize based > on the assumption there are no infinities or NaNs. FP operations can still > produce infinities or NaNs, the compiler just doesn't need to worry about > treating them correctly, and it's the programmer's reponsibility to ensure > they are not generated. > > > so I must check for > > !HONOR_SIGNED_ZEROS (type) && HONOR_NANS (type) && HONOR_INFINITIES (type) > > that is correct? Also, is it safe to remove the !finite_math_only with > > this, as now it is stated that the type supports infinity and NaNs? > > No that doesn't look quite right. First check whether the transformation > handles zero/inf/NaN correctly, if so you don't need any of this. > It does handle these correctly, as far as I am concerned. At least in IEEE 754. Richard Biener asked to add !flag_siged_zeros for documentation reasons but this is already covered by unsafe-math. I also checked the flags from the optimization page, but only unsafe math seems to be applicable. https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html So maybe just check for unsafe-math? > > > However, I am not sure if it is OK to remove unsafe-math-optimizations > > even if it enables > > finite_math_only because of the 2 ULP error. As stated in the first > > iteration, the user can be > > using a very precise math library that yields 0 ULP. > > Well 0 ULP would be an impossibility. Unsafe math seems reasonable since > it does behave slightly differently (including in terms of exception flags > set). > It's unfortunate GCC doesn't have clear definition of IEEE conformance > modes like various other compilers. > > Wilco > > >
