While looking into moving optimizations from minmax_replacement
in phiopt to match.pd, I Noticed that min/max were considered
trapping even if -ffinite-math-only was being used. This changes
those expressions to be similar as comparisons so that they are
not considered trapping if -ffinite-math-only is on.
OK? Bootstrapped and tested with no regressions on x86_64-linux-gnu.
gcc/ChangeLog:
* rtlanal.cc (may_trap_p_1): Treat SMIN/SMAX similar as
COMPARISON.
* tree-eh.cc (operation_could_trap_helper_p): Treate
MIN_EXPR/MAX_EXPR similar as other comparisons.
---
gcc/rtlanal.cc | 3 +++
gcc/tree-eh.cc | 3 +++
2 files changed, 6 insertions(+)
diff --git a/gcc/rtlanal.cc b/gcc/rtlanal.cc
index c96a88cebf1..b7948ecfad1 100644
--- a/gcc/rtlanal.cc
+++ b/gcc/rtlanal.cc
@@ -3204,6 +3204,9 @@ may_trap_p_1 (const_rtx x, unsigned flags)
case LT:
case LTGT:
case COMPARE:
+ /* Treat min/max similar as comparisons. */
+ case SMIN:
+ case SMAX:
/* Some floating point comparisons may trap. */
if (!flag_trapping_math)
break;
diff --git a/gcc/tree-eh.cc b/gcc/tree-eh.cc
index 41cf57d2b30..dbaa27d95c5 100644
--- a/gcc/tree-eh.cc
+++ b/gcc/tree-eh.cc
@@ -2490,6 +2490,9 @@ operation_could_trap_helper_p (enum tree_code op,
case GT_EXPR:
case GE_EXPR:
case LTGT_EXPR:
+ /* MIN/MAX similar as LT/LE/GT/GE. */
+ case MIN_EXPR:
+ case MAX_EXPR:
/* Some floating point comparisons may trap. */
return honor_nans;
--
2.39.1
