https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
CCing Andrew and Aldy to see what the ranger does or can do, talking about #c4.
So, we could:
--- gcc/match.pd.jj     2020-02-15 12:52:27.800034587 +0100
+++ gcc/match.pd        2020-03-04 12:25:12.744289050 +0100
@@ -1551,11 +1551,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 /* X / C1 op C2 into a simple range test.  */
 (for cmp (simple_comparison)
  (simplify
-  (cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2)
+  (cmp (trunc_div@3 @0 INTEGER_CST@1) INTEGER_CST@2)
   (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
        && integer_nonzerop (@1)
        && !TREE_OVERFLOW (@1)
-       && !TREE_OVERFLOW (@2))
+       && !TREE_OVERFLOW (@2)
+       && single_use (@3))
    (with { tree lo, hi; bool neg_overflow;
           enum tree_code code = fold_div_compare (cmp, @1, @2, &lo, &hi,
                                                   &neg_overflow); }
and thus not optimize those
  h_1 = x_2 / 3600;
  h_1 <= 24;
and
  h_1 >= 0;
into
  x_2 <= 89999;
and
  x_2 >= -3599;
because we have another h_1 use.  But, unfortunately that would pessimize the
case where there are multiple uses, but all of them can be optimized this way
(e.g. like that h_1 <= 24 and h_1 >= 0 uses), we'd keep a useless division.

I'd hope that with this optimization disabled or on #c5 ranger can handle the
testcase right (assuming the warning uses the ranger APIs), but the question is
can or could ranger handle even the case after this fold div compare
optimization?  I mean, if we have:
  h_1 = x_2 / 3600;
  if (x_2 <= -3599 && x_2 <= 89999)
    use (h_1);
figure out that h_1 is set to x_2 / 3600 and even when that SSA_NAME_DEF_STMT
is not in a guarded block, its use is in one and so from the [-3599, 89999]
range of x_2 at the point of use derive that h_1 there is [0, 24]?
Surely if it is like:
  if (x_2 <= -3599 && x_2 <= 89999)
    {
      h_1 = x_2 / 3600;
      use (h_1);
    }
I'd expect it to handle it that way.

Reply via email to