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