[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2018-01-29 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2018-01-28 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819

--- Comment #5 from Arseny Solokha  ---
Should we close this PR now?

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 24 09:31:56 2018
New Revision: 257012

URL: https://gcc.gnu.org/viewcvs?rev=257012=gcc=rev
Log:
2018-01-24  Richard Biener  

PR tree-optimization/82819
* graphite-isl-ast-to-gimple.c (binary_op_to_tree): Avoid
code generating pluses that are no-ops in the target precision.

* gcc.dg/graphite/pr82819.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr82819.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2018-01-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819

--- Comment #3 from Richard Biener  ---
I _think_ that in this particular case (and maybe others) we can avoid the
issue by not telling ISL anything about s4 -- this means treating s4 += xn
(which has
associated PHIs and loop-closed PHIs) as black-boxes.  This probably also means
we can't handle the if (s4 != 0) stmt in itself (we'd need to treat the
sub-CFG controlled by it as black-box).

So in the end this requires re-writing what GRAPHITE associates with a
black-box,
aka ISL user stmt, making it not only possibly sub-BB granular but also
possibly
covering more than one BB (and in case there is no dependence the black boxes
might even overlap in the original GIMPLE - but a valid pre-transform would be
to re-schedule GIMPLE stmts to make them non-overlapping).

That said, the issue is the following original AST:

[scheduler] original ast:
for (int c0 = 0; c0 < -P_2; c0 += 1) {
  S_4(c0);
  for (int c1 = 0; c1 <= 2; c1 += 1)
S_5(c0, c1);
  S_16(c0);
  if (P_19 + 6 * c0 == 18446744073709551610)
S_9((-P_19 + 18446744073709551610) / 6);
  S_10(c0);
}

where the if in the AST is from

 [local count: 39370534]:
# ns.1_30 = PHI 
# s4_29 = PHI 
# b2_31 = PHI <(3), b2_13(12)>
...

 [local count: 39370534]:
s4_22 = s4_29 + 6;
if (s4_22 != 0)
  goto ; [50.00%]
else
  goto ; [50.00%]

and the scalar evolution of s4_22 in the region is {s4_19(D) + 6, +, 6}_1.
Looks like the zero test is obfuscated a bit ... the pw_aff for s4_22 is

[P_2, P_19] -> { S_9[i1] -> [(6 + P_19 + 6i1 - 18446744073709551616*floor((6 +
P_19 + 6i1)/18446744073709551616))] }

where the obfuscation is from the chrec initial value s4_19(D) + 6 which
is computed in unsigned arithmetic and thus has to properly support
wrapping.

One thing would be to do more clever pattern matching during code-generation
handling for no-ops.  In this particular case

Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 256977)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -326,7 +326,8 @@ binary_op_to_tree (tree type, __isl_take
   /* From our constraint generation we may get modulo operations that
  we cannot represent explicitely but that are no-ops for TYPE.
  Elide those.  */
-  if (expr_type == isl_ast_op_pdiv_r
+  if ((expr_type == isl_ast_op_pdiv_r
+   || expr_type == isl_ast_op_add)
   && isl_ast_expr_get_type (arg_expr) == isl_ast_expr_int
   && (wi::exact_log2 (widest_int_from_isl_expr_int (arg_expr))
  >= TYPE_PRECISION (type)))

is a fix.

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2017-11-29 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2017-11-03 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking

--- Comment #2 from Richard Biener  ---
Ok, so it's caused by us tiling the original schedule and ISL splitting the
outer loop.

for (int c0 = 0; c0 < -P_2; c0 += 1) {
  S_4(c0);
  for (int c1 = 0; c1 <= 2; c1 += 1)
S_5(c0, c1);
  S_16(c0);
  if (P_19 + 6 * c0 == 18446744073709551610)
S_9((-P_19 + 18446744073709551610) / 6);
  S_10(c0);
}

becomes

  for (int c0 = P_19; c0 <= min(18446744073709551609, -6 * P_2 + P_19 - 6); c0
+= 6) {
S_4((-P_19 + c0) / 6);
S_16((-P_19 + c0) / 6);
for (int c2 = 0; c2 <= 2; c2 += 1)
  S_5((-P_19 + c0) / 6, c2);
S_10((-P_19 + c0) / 6);
  }
  if (P_19 >= 6 * P_2 + 18446744073709551616 && (P_19 - 4) % 6 == 0) {
S_16((-P_19 + 18446744073709551610) / 6);
S_4((-P_19 + 18446744073709551610) / 6);
for (int c2 = 0; c2 <= 2; c2 += 1)
  S_5((-P_19 + 18446744073709551610) / 6, c2);
S_9((-P_19 + 18446744073709551610) / 6);
S_10((-P_19 + 18446744073709551610) / 6);
  }
  for (int c0 = ((P_19 + 1) % 6) + 18446744073709551611; c0 < -6 * P_2 + P_19 -
5; c0 += 6) {
S_4((-P_19 + c0) / 6);
S_16((-P_19 + c0) / 6);
for (int c2 = 0; c2 <= 2; c2 += 1)
  S_5((-P_19 + c0) / 6, c2);
S_10((-P_19 + c0) / 6);
  }

exposing constants that are too large for our choosen code-generation type
(signed long long).

For some reason -fgraphite-identity performs a similar "transform".

Note that this code-gen error is somewhat "expected" until we do better
with selecting wider types for code-generation.  Note that
18446744073709551616 doesn't even fit unsigned long long.  For -m64 we
use __int128 which is why the bug doesn't trigger there.

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2017-11-03 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc-*-linux-gnu*,   |powerpc-*-linux-gnu*,
   |powerpcspe-*-linux-gnu* |powerpcspe-*-linux-gnu*,
   ||i?86-*-*
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-03
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed on x86_64-linux with -m32.  I will have a looksee.