--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 18:53
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Zdenek,
or simply use dominated_by_p, which is not too expensive -
only a couple of if statements, assuming the dominator
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 19:08
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
Note that recording tmp_1 = next_2 isn't particularly good either since
tmp_1 really isn't equivalent to next_2. It's
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 19:57
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
I think so. :-)
I don't. :( I think it'll record tmp_1 = next_2, which is actually
wrong, even though it doesn't
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 20:14
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
BTW, I may have a nice clean way to deal with this problem which doesn't
depend on us not walking the SSA_NAME_VALUE chain
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 21:31
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
Err, no. You're totally warping how the the equivalency code is meant
to work. It's a symmetric relationship and it's your
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 22:25
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
Can you come up with a hypothetical scenario?
No need. It's fundamentally broken in that it's recording
an invalid
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 16:57
---
Created an attachment (id=7714)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7714action=view)
a new patch
I think this new patch is conceptually more correct.
See the comments in the patch
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 16:58
---
With my old patch (conservative-dom), stmt.c was miscompiled on my machine.
stage2/cc1 crashes on compiling crtstuff.c.
Replacing stmt.o with stage1/stmt.o worked for me.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 16:59
---
Jeff,
I agree with your comment #26.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching
--
What|Removed |Added
CC||kazu at cs dot umass dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- You are receiving
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 19:22
---
Jeff,
With my new patch, stmt.i gets one fewer jump threading opportunities
(compared to what the vanilla mainline produces).
So it's very plausible that we are miscompiling stmt.c quietly.
This difference
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 20:02
---
Created an attachment (id=7715)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7715action=view)
a new patch
This patch is basically the same as the last patch except that
I've added a fast path
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 00:28
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
I believe your fast-path check is effectively equivalent to
if ((e-flags EDGE_DFS_BACK) == 0)
I see that we call
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 02:17
---
A patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00727.html
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|NEW
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 00:47
---
I took Steven's testcase in comment #12,
fed into GCC,
took its .t13.cfg output,
reformatted into C code,
fed that back into GCC with -O0,
and now I get the 5 5 garbage.
I separated main() to a separate file
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 00:58
---
Forget about comment #13.
My bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 01:32
---
Here is a complete testcase that fails at DOM1.
With -O0, this testcase prints 5 5 5.
With -O1, this testcase prints 5 5 0.
I generated this testcase from final_cleanup after disabling DOM[123].
extern int
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 02:14
---
DOM1 is translating tmp_4 d_5 (in L2:) into d23_2 d23_2,
which would be false.
So the threader itself doesn't seem to be broken. Something else is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 02:51
---
Here are the PHI nodes that I am getting at L2 in thread_across_edge
called on edge L23 - L2.
TMT.0_24 = PHI TMT.0_26(1), TMT.0_23(5);
ivtmp14_6 = PHI 0(1), ivtmp14_14(5);
d_5 = PHI d23_9(1), d23_2(5
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 03:26
---
I meant:
At this point, it's not safe to use SSA_NAME_VALUE for tmp_4.
Maybe we shouldn't add equivalence of tmp_4 and d_5 in the first place
if d_5 is also defined in a PHI node at the same BB.
--
http
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 03:35
---
Created an attachment (id=7710)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7710action=view)
a patch
This patch is fixes the bug but maybe a bit too conservative.
If thread_across_edge gets
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 05:24
---
Updated the testcase like so:
/* PR tree-optimization/18694
The dominator optimization didn't take the PHI evaluation order
into account when threading an edge. */
extern void abort (void
--- Additional Comments From kazu at cs dot umass dot edu 2004-03-25 19:16
---
Even if you split the long move in ix86_expand_move,
the constant 0 is propagated into the two moves.
I guess the right way may be uncse sometime after register allocation.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From kazu at cs dot umass dot edu 2004-02-01 17:24
---
Then we need something like an un-cse pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11877
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11877
--- You are receiving this mail because: ---
--- Additional Comments From kazu at cs dot umass dot edu 2004-01-04 06:55
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00153.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11877
--- You are receiving this mail because: ---
You reported the bug
--- Additional Comments From kazu at cs dot umass dot edu 2003-12-31 21:19
---
(set (mem:DI ...) (const_int 0)) is split into two moves in SImode after reload.
We could delay the split until after peephole2.
In peephole2, if a scratch reg is available,
load 0 into it with XOR
28 matches
Mail list logo
