https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Various match.pd patterns use predicates like:
(simplify
(mult @0 real_zerop@1)
(if (!tree_expr_maybe_nan_p (@0)
&& (!HONOR_NANS (type) || !tree_expr_maybe_infinite_p (@0))
&& (!HONOR_SIGNED_ZEROS (type) || tree_expr_nonnegative_p (@0)))
@1))
/* In IEEE floating point, x*1 is not equivalent to x for snans.
Likewise for complex arithmetic with signed zeros. */
(simplify
(mult @0 real_onep)
(if (!tree_expr_maybe_signaling_nan_p (@0)
&& (!HONOR_SIGNED_ZEROS (type)
|| !COMPLEX_FLOAT_TYPE_P (type)))
(non_lvalue @0)))
etc. which would be great if it could use frange. Though, I think we also run
here into the problem that match.pd right now avoids the ranger because it
could reliably only allow walks from uses to SSA_NAME_DEF_STMTs and not the
other direction.
But of course those few simplifications are simple enough that they could be
also repeated somewhere in the e?vrp code.
One thing to consider is that at runtime, not all arithmetics might be as
precise as what mpfr does at compile time, so in some cases it should expect a
few ulps or maybe even more than that as possible errors (especially for
library functions). And also take into account different rounding modes if
user wants that to be honored.
As for exceptions, I guess one thing is that ranger computes ranges and another
thing is that optimization based on that will sometimes need to punt if it
could optimize away visible side-effects the user cares about.
