[Bug tree-optimization/59817] ICE in extract_affine_chrec with -O2 -ftree-loop-linear

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The ICE tells us that the parameter isn't recorded as parameter in the SESE
region:

(gdb) p debug_scop_params (s, 2)
# parameters (
# Parameter names are provided
1
# Parameter names
_10 pretmp_30 offset.3_15 
#)
$28 = void
(gdb) p debug_scop_params (s, 5)
# parameters (
# Parameter names are provided
1
# Parameter names
_10 pretmp_30 offset.3_15 
#)
$29 = void

(gdb) p debug_scop (s, 1)
SCoP 1
#(
# Language
Gimple
# Context (
#eq     p0     p1     p2    cst
XXX isl
# )
# Parameter names are provided
1
# Parameter names
_10 pretmp_30 offset.3_15 
# Number of statements
2

# Iteration domain of bb_8 (
#eq     i0     p0     p1     p2    cst
XXX isl
#)
# Access informations are provided
1
# Read access informations
0
# Write access informations
1
# data accesses (
#  eq   alias   sub0     i0     p0     p1     p2    cst
#)
# Statement body is not provided
0

# Iteration domain of bb_10 (
#eq     i0     i1     p0     p1     p2    cst
XXX isl
#)
# Access informations are not provided
0
# Statement body is not provided
0
#)
$32 = void

not sure if I interpret the above correctly but bb8 and bb10 seem to be in
that scop.  The parameter is refered from bb 8.

Ah, scan_tree_for_params does

scan_tree_for_params (sese s, tree e)
{
  if (e == chrec_dont_know)
    return;

  switch (TREE_CODE (e))
    {
    case POLYNOMIAL_CHREC:
      scan_tree_for_params (s, CHREC_LEFT (e));
      break;

thus it misses to scan CHREC_RIGHT.  The MULT_EXPR handling is also suspicious.

Fixing the above shifts the ICE to

#1  0x000000000132e1ae in extract_affine_chrec (s=0x1f89e10, e=
    <polynomial_chrec 0x7ffff6d91ae0>, space=0x1f8b910)
    at /space/rguenther/src/svn/trunk/gcc/graphite-sese-to-poly.c:619
619       gcc_assert (isl_pw_aff_is_cst (rhs)
(gdb) l
614       isl_aff *loop = isl_aff_set_coefficient_si
615         (isl_aff_zero_on_domain (ls), isl_dim_in, pos, 1);
616       isl_pw_aff *l = isl_pw_aff_from_aff (loop);
617
618       /* Before multiplying, make sure that the result is affine.  */
619       gcc_assert (isl_pw_aff_is_cst (rhs)
620                   || isl_pw_aff_is_cst (l));
621
622       return isl_pw_aff_add (lhs, isl_pw_aff_mul (rhs, l));
623     }

so maybe it simply doesn't handle CHRECs with variable stride but fails to
disregard those.

It indeed fails to as scev_is_linear_expression doesn't have the
same restriction on CHRECs as graphite_can_represent_scev asserts.
Thus completing that one as well is required.

Index: gcc/graphite-scop-detection.c
===================================================================
--- gcc/graphite-scop-detection.c       (revision 209292)
+++ gcc/graphite-scop-detection.c       (working copy)
@@ -219,7 +219,14 @@ graphite_can_represent_scev (tree scev)

   switch (TREE_CODE (scev))
     {
+    case NEGATE_EXPR:
+    case BIT_NOT_EXPR:
+    CASE_CONVERT:
+    case NON_LVALUE_EXPR:
+      return graphite_can_represent_scev (TREE_OPERAND (scev, 0));
+
     case PLUS_EXPR:
+    case POINTER_PLUS_EXPR:
     case MINUS_EXPR:
       return graphite_can_represent_scev (TREE_OPERAND (scev, 0))
        && graphite_can_represent_scev (TREE_OPERAND (scev, 1));
@@ -247,7 +254,8 @@ graphite_can_represent_scev (tree scev)
     }

   /* Only affine functions can be represented.  */
-  if (!scev_is_linear_expression (scev))
+  if (tree_contains_chrecs (scev, NULL)
+      || !scev_is_linear_expression (scev))
     return false;

   return true;