Reassociation and trapping operations

Ilya Leoshkevich
Wed Nov 25 01:38:37 GMT 2020


I have a C floating point comparison (a <= b && a >= b), which
test_for_singularity turns into (a <= b && a == b) and vectorizer turns
into ((a <= b) & (a == b)).  So far so good.

eliminate_redundant_comparison, however, turns it into just (a == b).
I don't think this is correct, because (a <= b) traps and (a == b)
doesn't.  The following helps:

--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -2144,7 +2144,7 @@ eliminate_redundant_comparison (enum tree_code
   if (TREE_CODE (curr->op) != SSA_NAME)
     return false;
   def1 = SSA_NAME_DEF_STMT (curr->op);
-  if (!is_gimple_assign (def1))
+  if (!is_gimple_assign (def1) || gimple_could_trap_p (def1))
     return false;
   lcode = gimple_assign_rhs_code (def1);
   if (TREE_CODE_CLASS (lcode) != tcc_comparison)
@@ -2160,7 +2160,7 @@ eliminate_redundant_comparison (enum tree_code
       if (TREE_CODE (oe->op) != SSA_NAME)
       def2 = SSA_NAME_DEF_STMT (oe->op);
-      if (!is_gimple_assign (def2))
+      if (!is_gimple_assign (def2) || gimple_could_trap_p (def2))
       rcode = gimple_assign_rhs_code (def2);
       if (TREE_CODE_CLASS (rcode) != tcc_comparison)

However, I couldn't help noticing that other parts of reassociation
pass use stmt_could_throw_p, and trapping is mentioned only in one
place.  Is this intentional?  Shouldn't both throwing and trapping
block reassociation?

Best regards,

More information about the Gcc mailing list