[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since g:a0b1798042d033fd2cc2c806afbb77875dd2909b

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-02-28
     Ever confirmed|0                           |1
                 CC|                            |amacleod at redhat dot com,
                   |                            |rsandifo at gcc dot gnu.org
   Target Milestone|---                         |14.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Do we have POLY_INT_CSTs in CHRECs?  Huh, yeah - we do.  So in IVOPTs the
differences are like

 (get_scalar_evolution 
   (scalar = col_i_61)
-  (scalar_evolution = {iftmp.0_11 * _105, +, iftmp.0_11}_2))
+  (scalar_evolution = (int) {(unsigned int) col_stride_10 * (unsigned int)
_105, +, (unsigned int) col_stride_10}_2))

but also

 (set_scalar_evolution 
   instantiated_below = 22 
   (scalar = _58)
-  (scalar_evolution = {(__fp16 *) p_mat_16(D) + ((long unsigned int) _105 +
(long unsigned int) (iftmp.0_11 * _105)) * 2, +, ((long unsigned int)
iftmp.0_11 + 1) * 2}_2))
+  (scalar_evolution = _58))

(that's completely missed)

Likewise, with POLY_INT_CST:

-  (scalar_evolution = {(__fp16 *) p_mat_16(D) + (((long unsigned int)
(iftmp.0_11 * _105) + (long unsigned int) _105) * 2 + POLY_INT_CST [16, 16]),
+, ((long unsigned int) iftmp.0_11 + 1) * 2}_2))
+  (scalar_evolution = _13))

The special-casing of CHREC * x we allow to be expressed works by looking
at value-ranges and signs of INTEGER_CSTs:

+         if (!ANY_INTEGRAL_TYPE_P (type)
+             || TYPE_OVERFLOW_WRAPS (type)
+             || integer_zerop (CHREC_LEFT (op0))
+             || (TREE_CODE (CHREC_LEFT (op0)) == INTEGER_CST
+                 && TREE_CODE (CHREC_RIGHT (op0)) == INTEGER_CST
+                 && (tree_int_cst_sgn (CHREC_LEFT (op0))
+                     == tree_int_cst_sgn (CHREC_RIGHT (op0))))
+             || (get_range_query (cfun)->range_of_expr (rl, CHREC_LEFT (op0
...

possibly there might be a way to adapt the "same sign" check to also work
for POLY_INT_CSTs which I think have known signs?  Possibly rewriting
that by using poly_int_tree_p () isntead of checking for INTEGER_CST
and then using known_lt (wi::to_poly_wide (), 0) && known_lt (..., 0)
|| known_gt (..., 0) && known_gt (..., 0) helps?

Nope, the following doesn't make a difference here.

diff --git a/gcc/tree-chrec.cc b/gcc/tree-chrec.cc
index 2e6c7356d3b..366ab914c8f 100644
--- a/gcc/tree-chrec.cc
+++ b/gcc/tree-chrec.cc
@@ -442,10 +442,12 @@ chrec_fold_multiply (tree type,
          if (!ANY_INTEGRAL_TYPE_P (type)
              || TYPE_OVERFLOW_WRAPS (type)
              || integer_zerop (CHREC_LEFT (op0))
-             || (TREE_CODE (CHREC_LEFT (op0)) == INTEGER_CST
-                 && TREE_CODE (CHREC_RIGHT (op0)) == INTEGER_CST
-                 && (tree_int_cst_sgn (CHREC_LEFT (op0))
-                     == tree_int_cst_sgn (CHREC_RIGHT (op0))))
+             || (poly_int_tree_p (CHREC_LEFT (op0))
+                 && poly_int_tree_p (CHREC_RIGHT (op0))
+                 && ((known_lt (wi::to_poly_widest (CHREC_LEFT (op0)), 0)
+                      && known_lt (wi::to_poly_widest (CHREC_RIGHT (op0)), 0))
+                     || (known_ge (wi::to_poly_widest (CHREC_LEFT (op0)), 0)
+                         && known_ge (wi::to_poly_widest (CHREC_RIGHT (op0)),
0))))
              || (get_range_query (cfun)->range_of_expr (rl, CHREC_LEFT (op0))
                  && !rl.undefined_p ()
                  && (rl.nonpositive_p () || rl.nonnegative_p ())


This was a correctness fix btw, so I'm not sure we can easily recover - we
could try using niter information for CHREC_VARIABLE but then there's
variable niter here so I don't see a chance.

This is mainly IVs like

  col_i_61 = col_stride_10 * j_73;
  _60 = (long unsigned int) col_i_61;
  _59 = _60 * 2;
  _58 = a_j_69 + _59;
  _54 = MEM <__SVFloat16_t> [(__fp16 *)_58];

where we compose for example the scalar evolution of col_i_61 by
multiplyinig that of j_73 which is {_105, +, 1}_2 with col_stride_10.

Possibly adding a ranger instance to IVOPTs could help, for this instance
since

  <bb 4> [local count: 118111600]:
  # col_stride_10 = PHI <size_15(D)(11), 1(2)>
  if (size_15(D) > 0)
    goto <bb 21>; [89.00%]
  else
    goto <bb 5>; [11.00%]

  <bb 5> [local count: 118111600]:
  return;

so col_stride_10 should be positive, and _105 as well:

  _12 = MAX_EXPR <_103, 0>;
  _3 = (unsigned int) _12;
  _4 = _3 + 1;
  _105 = (int) _4;

OTOH the +1 could make it overflow for large size.

Can you test the above?  It should be an incremental improvement.

Adding enable_ranger (cfun); / disable_ranger (cfun);  around the IVOPTs
pass doesn't seem to help (but see above - there might not be enough
info, also the code added doesn't pass in a context stmt so ranger
might not do much/anything here).

Confirmed.