--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-06 13:56
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #9 from matz at gcc dot gnu dot org 2010-05-06 13:55 ---
Subject: Bug 43984
Author: matz
Date: Thu May 6 13:54:32 2010
New Revision: 159106
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159106
Log:
PR tree-optimization/43984
* tree-ssa-pre.c (inser
--- Comment #8 from steven at gcc dot gnu dot org 2010-05-05 13:52 ---
I think that's an oversight, then. You shouldn't have to use the delayed edge
insert functions if you've pre-split all edges. Perhaps PRE can always use the
_immediate insert functions, and save a walk over all edges
--- Comment #7 from rguenther at suse dot de 2010-05-05 13:33 ---
Subject: Re: PRE misses full-redundancies,
inserts into loops
On Wed, 5 May 2010, steven at gcc dot gnu dot org wrote:
> --- Comment #5 from steven at gcc dot gnu dot org 2010-05-05 13:10
> ---
> I don't unde
--- Comment #6 from matz at gcc dot gnu dot org 2010-05-05 13:32 ---
PRE seems to have done this since forever. All edge inserts are delayed if
the _immediate forms aren't used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
--- Comment #5 from steven at gcc dot gnu dot org 2010-05-05 13:10 ---
I don't understand. We insert on edges now? Even though all critical edges are
split? I thought that if you insert on a critical edge, the commit is
instantanous, not delayed.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #4 from matz at gcc dot gnu dot org 2010-05-05 12:35 ---
Ah, another case of a patch I held back for 4.6 to open, and then forgetting
about it :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-05 12:20 ---
Nope. It's because we eliminate() before committing edge inserts. Oops.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-05 11:13 ---
Ah, it needs -fno-tree-dominator-opts.
We are performing insertion in non-optimal order. We are inserting in
BB11
|
BB12
/ \
BB44 BB45
and insert into BB45 before inserting into BB11, because walkin
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-04 17:22 ---
I don't see any insert of iyz.data. But from the sound of it, this seems
related to PR 38497.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
10 matches
Mail list logo