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: "pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Dec 2004 18:49:17 -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 pinskia at gcc dot gnu dot org 2004-12-30 18:49 -------
(In reply to comment #33)
> 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?
It has nothing to do with out-of-ssa any more, sorry for not being clear but here are the chain
of events for the current problem.
We split the critial edges so when we try to create the IV (in iv-opts), we insert an instruction on the bb
which is the empty and otherwise useless but if we had cleaned up the CFG before running IV-OPTS, we
would insert it right before the condition just like your patch does for out of ssa.
And now we have this extra bb that is not useless, out of ssa is going to use instead of using your new
scheme.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038