[Bug c/38446] New: [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
gloog calls rewrite_into_sese_closed_ssa, which in turn calls sese_find_uses_to_rename_bb. sese_find_uses_to_rename_bb looks at every phi in every basic block. For each incoming edge into that basic block which is associated with the corresponding use argument of the phi, graphite then calls sese_find_uses_to_rename_bb. Now for the use found, the def_bb is looked up. If the def_bb exists and def_bb belongs to the scop and use_bb does not belong to scope, then a phi is created that can reach the use_bb because def_bb does not reach use_bb. Right now the check which determines if def_bb belongs to the scop and use_bb does not belong to scop is broken since it looks at dominators and post dominators instead of travesing or looking up the bb's in scop which match with a given bb. -- Summary: [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: hjagasia at gcc dot gnu dot org ReportedBy: hjagasia at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug c/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
--- Comment #1 from hjagasia at gcc dot gnu dot org 2008-12-08 17:26 --- Created an attachment (id=16852) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16852&action=view) Reduced test case for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug middle-end/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
--- Comment #2 from hjagasia at gcc dot gnu dot org 2008-12-10 21:09 --- Created an attachment (id=16877) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16877&action=view) This patch fixes PR38446 by explicitly checking if bb belongs to sese region by looking at all bbs in scop instead of using dominator/post-dominator information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug middle-end/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
--- Comment #3 from hjagasia at gcc dot gnu dot org 2008-12-10 22:34 --- Created an attachment (id=16880) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16880&action=view) Updated patch reviewed by Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug middle-end/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
--- Comment #5 from hjagasia at gcc dot gnu dot org 2008-12-11 17:27 --- Subject: Bug 38446 Author: hjagasia Date: Thu Dec 11 17:26:28 2008 New Revision: 142685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142685 Log: 2008-12-11 Harsha Jagasia PR tree-optimization/38446 * gcc.dg/graphite/pr38446.c: New. * graphite.c (register_bb_in_sese): New. (bb_in_sese_p): Check if bb belongs to sese region by explicitly looking at the bbs in the region. * graphite.h (sese): Add region_basic_blocks pointer set to structure and initialize at the time of defining new scop. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr38446.c Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c branches/graphite/gcc/graphite.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #2 from hjagasia at gcc dot gnu dot org 2008-12-12 22:27 --- Created an attachment (id=16898) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16898&action=view) Proposed Patch 2008-12-12 Jan Sjodin Harsha Jagasia PR tree-optimization/38500 * gcc.dg/graphite/pr38500.c: New. * graphite.c (create_sese_edges): Call fix_loop_structure after splitting blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #4 from hjagasia at gcc dot gnu dot org 2008-12-12 23:01 --- Created an attachment (id=16900) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16900&action=view) Forgot to add testcase to patch, updating patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #5 from hjagasia at gcc dot gnu dot org 2008-12-12 23:06 --- Subject: Bug 38500 Author: hjagasia Date: Fri Dec 12 23:05:09 2008 New Revision: 142728 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142728 Log: 2008-12-12 Jan Sjodin Harsha Jagasia PR tree-optimization/38500 * gcc.dg/graphite/pr38500.c: New. * graphite.c (create_sese_edges): Call fix_loop_structure after splitting blocks. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr38500.c Modified: branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #3 from hjagasia at gcc dot gnu dot org 2008-12-19 05:31 --- Created an attachment (id=16942) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16942&action=view) Proposed patch 2008-12-18 Harsha Jagasia PR tree-optimization/38510 * gcc.dg/graphite/pr38510.c: New. * graphite.c (translate_clast): Call mark_irreducible_loops before graphite_verify. (gloog): Call mark_irreducible_loops before graphite_verify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #4 from hjagasia at gcc dot gnu dot org 2008-12-19 18:20 --- Created an attachment (id=16946) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16946&action=view) Fixed changes suggested by Sebastian Pop. 2008-12-19 Harsha Jagasia PR tree-optimization/38510 * gcc.dg/graphite/pr38510.c: New. * graphite.c (recompute_all_dominators): Call mark_irreducible_loops. (translate_clast): Call recompute_all_dominators before graphite_verify. (gloog): Call recompute_all_dominators before graphite_verify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #7 from hjagasia at gcc dot gnu dot org 2008-12-22 19:26 --- Subject: Bug 38510 Author: hjagasia Date: Mon Dec 22 19:24:59 2008 New Revision: 142888 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142888 Log: 2008-12-22 Harsha Jagasia PR tree-optimization/38510 * gcc.dg/graphite/pr38510.c: New. * graphite.c (recompute_all_dominators): Call mark_irreducible_loops. (translate_clast): Call recompute_all_dominators before graphite_verify. (gloog): Call recompute_all_dominators before graphite_verify. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr38510.c Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug middle-end/38559] [graphite] ICE :in build2_stat, at tree.c:3293
--- Comment #2 from hjagasia at gcc dot gnu dot org 2008-12-22 19:41
---
For the clast_stmt below:
if (midend_8 >= mid_10+1) {
for (s_3=0;s_3<=min(midend_8-mid_10-1,63);s_3++) {
S5(0,s_3) ;
}
}
graphite gets into
translate_clast:stmt_guard->graphite_create_new_guard->graphite_create_guard_cond_expr->graphite_translate_clast_equation->clast_to_gcc_expression
Finally graphite calls
fold_build2 (PLUS_EXPR, type, tl, tr);
which in turn calls
build2_stat (code, type, op0, op1, PASS_MEM_STAT);
Finally for the RHS of the clast guard equation "if (midend_8 >= mid_10+1)"
the following code is invoked:
if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR)
&& arg0 && arg1 && tt && POINTER_TYPE_P (tt))
gcc_assert (TREE_CODE (arg0) == INTEGER_CST || TREE_CODE (arg1) ==
INTEGER_CST);
For the RHS, "mid_10+1", the TREE_CODE of "mid_10" is SSA_NAME and that of "1"
is INTEGER_CST.
Hence the gcc_assert raises an assertion.
--
hjagasia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-12-22 19:41:18
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38559
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
-- hjagasia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hjagasia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-12 15:42:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #3 from hjagasia at gcc dot gnu dot org 2008-09-12 15:44 --- Jan and I have a bug fix for this, which will be posted in some time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #4 from hjagasia at gcc dot gnu dot org 2008-09-12 16:52 --- The reduced test case block-2.c triggers 3 seperate bugs. First: In tranlate_clast when clast stmt is a stmt_user, we can end up disconnecting the edge that is the exit_edge of the scop that is transformed. This state creates problems because the exit_edge no longer has a destination. Hence when after translate_clast, the exit_edge is redirected with redirect_edge_succ, the edge is already disconnected. Second: Graphite does not handle clast user stmts with constant arguments. Third: Graphite can create scops which overlap. This is an issue if one of the overlapping scops is transformed which can cause some edges to be redirected. When the successive overlapping scops are attempted to be transformed, the basic blocks in the scop are no longer the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #5 from hjagasia at gcc dot gnu dot org 2008-09-12 16:54 --- Created an attachment (id=16304) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16304&action=view) This patch fixes all three problems in the reduced test case block-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #6 from hjagasia at gcc dot gnu dot org 2008-09-12 16:59 --- 2008-09-05 Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> * graphite.c (gmp_cst_to_tree): Moved. (iv_stack_entry_is_constant): New. (iv_stack_entry_is_iv): New. (loop_iv_stack_push): Renamed to loop_iv_stack_push_iv. (loop_iv_stack_insert_constant): New. (loop_iv_stack_pop): Use new datatpype. (loop_iv_stack_get_iv): Same. (loop_iv_stack_get_iv_from_name): Same. (loop_iv_stack_debug): Renamed to debug_loop_iv_stack. (loop_iv_stack_patch_for_consts): New. (loop_iv_stack_remove_constants): New. (graphite_create_new_loop): Use loop_iv_stack_push_iv. (translate_clast): Call loop_iv_stack_patch_for_consts and loop_iv_stack_remove_constants. (gloog): Use new datatype. Redirect construction edge to end block to avoid accidental deletion. (limit_scops): Prevent overlapping scops. * graphite.h (enum iv_stack_entry_kind): New. Tag for data in iv stack entry. (union iv_stack_entry_data): New. Data in iv stack entry. (struct iv_stack_entry): New. Datatype for iv stack entries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug c/37684] New: [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar
When translate_clast is called for a scop, scalar definitions are optimized out
and hence any subsequent uses of those scalars, outside the scop, represents a
problem. Also as code is generated for a scop, basic blocks in the scop are
moved around such that the block which contains the definition of a scalar no
longer dominates the basic block outside the scop which contains a use of that
scalar.
Attached reduced testcase block-3.c (derived from cpu2006-401.bzip2-bzlib.c)
fails in gloog->verify_ssa->verify_use at below:
>>>
else if (bb != def_bb
&& !dominated_by_p (CDI_DOMINATORS, bb, def_bb))
{
error ("definition in block %i does not dominate use in block %i",
def_bb->index, bb->index);
err = true;
}
>>>
Before translate_clast is called, here is an excerpt from the function:
:
# SMT.48_24 = PHI
# i_28 = PHI
# SMT.49_29 = PHI
# SMT.48_20 = VDEF
# SMT.49_21 = VDEF
s_5->inUse[i_28] = 0;
i_10 = i_28 + 1;
if (i_10 <= 255)
goto ;
else
goto ;
:
goto ;
:
:
# VUSE
D.1656_11 = s_5->blockNo;
D.1657_12 = D.1656_11 + 1;
# SMT.48_22 = VDEF
# SMT.49_23 = VDEF
s_5->blockNo = D.1657_12;
return;
At this point bb 3 which contains the VDEF for SMT.48_20 and SMT.49_21
dominates bb 6 which contains the VUSE for the same. The VDEF is associated
with s_5->blockNo and the VUSE with s_5->inUse[i_28].
After translate_clast is called, here is an excerpt from the function:
BZ2_bzCompressInit (struct bz_stream * strm, int blockSize100k, int verbosity,
int workFactor)
{
struct EState * D.1728;
int D.1725;
int D.1726;
int D.1727;
int graphiteIV.63;
int graphiteIV.62;
Int32 pretmp.52;
int D.1656;
int D.1657;
Int32 i;
struct EState * s;
void * D.1643;
void * D.1642;
void * (*) (void *, int, int) D.1641;
:
# VUSE
D.1641_2 = strm_1(D)->bzalloc;
# VUSE
D.1642_3 = strm_1(D)->opaque;
# SMT.47_17 = VDEF
# SMT.48_18 = VDEF
# SMT.49_19 = VDEF
D.1643_4 = D.1641_2 (D.1642_3, 304, 1);
s_5 = (struct EState *) D.1643_4;
:
# graphiteIV.62_13 = PHI <0(2), graphiteIV.62_6(8)>
graphiteIV.62_6 = graphiteIV.62_13 + 1;
if (graphiteIV.62_6 <= 3)
goto ;
else
goto ;
:
graphiteIV.63_9 = graphiteIV.62_13 * 64;
:
# graphiteIV.63_27 = PHI
# SMT.48_24 = PHI <>
# SMT.49_29 = PHI <>
graphiteIV.63_25 = graphiteIV.63_27 + 1;
D.1725_26 = graphiteIV.62_13 * 64;
D.1726_30 = D.1725_26 + 63;
D.1727_31 = MIN_EXPR ;
if (graphiteIV.63_25 <= D.1727_31)
goto ;
else
goto ;
:
goto ;
:
goto ;
:
Invalid sum of outgoing probabilities 0.0%
Invalid sum of incoming frequencies 25, should be 9900
D.1728_32 = (struct EState *) D.1643_4;
D.1728_32->inUse[graphiteIV.63_27] = 0;
goto ;
:
Invalid sum of incoming frequencies 0, should be 9800
:
:
# VUSE
D.1656_11 = s_5->blockNo;
D.1657_12 = D.1656_11 + 1;
# SMT.48_22 = VDEF
# SMT.49_23 = VDEF
s_5->blockNo = D.1657_12;
return;
}
During translate_clast the scop is transformed and the scalar VDEFS for
SMT.48_20, SMT.49_21 are removed by graphite. Also bb 3 no longer
dominates bb 6.
--
Summary: [graphite] basic block containing VDEF of a scalar does
not dominate basic block containing VUSE of the same
scalar
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: hjagasia at gcc dot gnu dot org
ReportedBy: hjagasia at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37684
[Bug c/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar
--- Comment #1 from hjagasia at gcc dot gnu dot org 2008-09-30 16:34 --- Created an attachment (id=16434) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16434&action=view) Reduced test case derived from CPU2006 401.bzip2 benchmark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37684
[Bug tree-optimization/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar
--- Comment #2 from hjagasia at gcc dot gnu dot org 2008-09-30 16:40 --- Created an attachment (id=16435) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16435&action=view) This patch fixes the reduced test case block-3.c Until graphite can handle scalars and also update dominance properly (planned for gcc 4.5), this patch will work by limiting the scop that contains bb 3, which in turn contains the VDEFs for SMT.48_20, SMT.49_21, such that no code is generated for it. This patch depends on the patch submitted for 37485. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37684
