[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715 --- Comment #11 from Richard Biener --- Author: rguenth Date: Thu Jan 9 09:21:02 2014 New Revision: 206460 URL: http://gcc.gnu.org/viewcvs?rev=206460&root=gcc&view=rev Log: 2014-01-09 Richard Biener PR tree-optimization/59715 * tree-cfg.h (split_critical_edges): Declare. * tree-cfg.c (split_critical_edges): Export. * tree-ssa-sink.c (execute_sink_code): Split critical edges. * gcc.dg/torture/pr59715.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59715.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-cfg.h trunk/gcc/tree-ssa-sink.c
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715 --- Comment #10 from Richard Biener --- Created attachment 31775 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31775&action=edit alternative patch Alternative patch splitting critical edges again. I'm going to test that, it fixes optimization regressions from at least 4.3 where critical edges were still split reliably.
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715 --- Comment #9 from Richard Biener --- Created attachment 31774 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31774&action=edit untested patch Like with the attached patch which performs edge-insertion. But it doesn't work that way because incrementally sinking then isn't able to figure out a destination gsi (we can't do gsi_for_stmt on an edge-insertion-queued stmt, bah). But otherwise it fixes the bug ... Leaves to disable the sinking, it's not the optimal insertion place anyway (if not inserting on the edge). Or to re-run critical edge splitting.
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715
--- Comment #8 from Richard Biener ---
virtual SSA form is broken, we have overlapping life-ranges - a virtual PHI
node is missing in bb 6, seems to be broken by store sinking (-fno-tree-sink
fixes it). The virtual SSA form updating is too simple:
/* Update virtual operands of statements in the path we
do not sink to. */
if (gimple_vdef (stmt))
{
imm_use_iterator iter;
use_operand_p use_p;
gimple vuse_stmt;
FOR_EACH_IMM_USE_STMT (vuse_stmt, iter, gimple_vdef (stmt))
if (gimple_code (vuse_stmt) != GIMPLE_PHI)
FOR_EACH_IMM_USE_ON_STMT (use_p, iter)
SET_USE (use_p, gimple_vuse (stmt));
}
as in this case we sink
store
| \
x |
/ \ |
/ \ y ---
/ \
needed-here\
but not here
sinking assumes that critical edges are split - but tail-merging breaks this
assumption, breaking sinking. With critical edges split we can insert
on the edge to needed-here.
Either dumb down sinking (detect the critical edge case and don't sink),
make it insert on edges instead, or restore previous behavior to have
critical edges split after PRE (note it may be already partly broken
before as cfg-cleanup unsplits edges again).
So it is tail-merging introducing this after all, but not necessarily
tail-mergings fault.
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- Mine then.
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715 vries at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from vries at gcc dot gnu.org --- The redundant store elimination in tree-ssa-dom.c:optimize_stmt (introduced in PR45705) removes the non-redundant store b = 0.
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715
--- Comment #5 from vries at gcc dot gnu.org ---
The test passes with -fno-tree-tail-merge. But I don't see anything wrong with
the transformation (merging of empty blocks) done by the pass.
AFAICT, the problem is introduced by pass_dominator. test.c.126t.slsr looks ok,
but test.c.127t.dom2 look wrong. The test passes with -fno-tree-dominator-opts.
test.c.126t.slsr:
...
:
b.0_4 = b;
if (b.0_4 == 0)
goto ;
else
goto ;
:
goto ;
:
a.1_5 = a;
if (a.1_5 != 0)
goto ;
else
goto ;
:
b = a.1_5;
c_7 = 1 % a.1_5;
if (c_7 != 0)
goto ;
else
goto ;
:
b = 0;
:
b.0_9 = b;
printf ("%d\n", b.0_9);
return 0;
...
we're taking the path bb2 -> bb4 -> bb5 (b = 2) -> bb6 (b = 0) -> bb7
test.c.127t.dom2:
...
:
b.0_4 = b;
if (b.0_4 == 0)
goto ;
else
goto ;
:
goto ;
:
a.1_5 = a;
if (a.1_5 != 0)
goto ;
else
goto ;
:
b = a.1_5;
c_7 = 1 % a.1_5;
if (c_7 != 0)
goto ;
else
goto ;
:
b.0_9 = b;
printf ("%d\n", b.0_9);
return 0;
...
we're taking the path bb2 -> bb4 -> bb5 (b = 2) -> bb6
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715 Steven Bosscher changed: What|Removed |Added Status|REOPENED|NEW --- Comment #4 from Steven Bosscher --- (In reply to Jakub Jelinek from comment #2) > Nope, b is initialized to 0. Eh, right, sorry!
[Bug tree-optimization/59715] [4.7/4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59715 Jakub Jelinek changed: What|Removed |Added CC||vries at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|wrong code at -Os and above |[4.7/4.8/4.9 Regression] |on x86_64-linux-gnu |wrong code at -Os and above ||on x86_64-linux-gnu --- Comment #3 from Jakub Jelinek --- Started with r179275.
