--- 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 rec
--- 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 relat
--- 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_
--- 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,
--- 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
--- 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&qu
--
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-10 02:17
---
A patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00727.html
--
What|Removed |Added
--- 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
--- 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=7715&action=view)
a new patch
This patch is basically the same as the last patch except that
I've added a f
--- 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 diffe
--
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 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
--- 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:57
---
Created an attachment (id=7714)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7714&action=view)
a new patch
I think this new patch is conceptually more correct.
See the comments in th
--- 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
--- 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=7710&action=view)
a patch
This patch is fixes the bug but maybe a bit too conservative.
If thread_across_edge
--- 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.
--- 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 ;
ivtmp14_6 = PHI <0(1), ivtmp14_14(5)>;
d_5 = PHI ; <- defined
tmp_4 = PHI ; &
--- 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
--- 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 disabli
--- 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 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(
--- 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, or
--- 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 and then
28 matches
Mail list logo
