This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/59817] ICE in extract_affine_chrec with -O2 -ftree-loop-linear
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 11 Apr 2014 10:27:34 +0000
- Subject: [Bug tree-optimization/59817] ICE in extract_affine_chrec with -O2 -ftree-loop-linear
- Auto-submitted: auto-generated
- References: <bug-59817-4 at http dot gcc dot gnu dot org/bugzilla/>
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;