This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Dec 2004 18:39:44 -0000
- Subject: [Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB
- References: <20041216155140.19038.dje@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From law at redhat dot com 2004-12-30 18:39 -------
Subject: Re: [4.0 Regression] out-of ssa
causing loops to have more than one BB
On Thu, 2004-12-30 at 17:27 +0000, pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 17:27 -------
> (In reply to comment #31)
> > Subject: Re: [4.0 Regression] out-of ssa
> > causing loops to have more than one BB
>
> > Now if you think that PR is a trivial case that should be caught, then,
> > show me why and I'll take a closer look.
>
> The reason why it is not caught is because we don't cleanup the cfg while doing the
> loop optimizations, this has been fixed already on the tcb.
Can you be more precise how cleaning up the CFG during the loop
optimizer affects the code that we see during out-of-ssa. Specifically
how does it affect PHI arguments on backedges and the proper marking
of backedges in the CFG?
>
> Oh, by the way I see that sixtrack has regressed on x86 now with your patch applied, I think this is
> because we still have the same problem as before as ivopts puts the new instruction in an empty BB
> which becomes from not cleaning up the cfg.
Again, more information please on how this affects us during out-of-ssa?
I'm happy to look into these problems, but you've apparently got a lot
more state on them than I do. I'd like to learn what you already know
to speed up that process.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038