This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Loop analysis
- From: Jan Hubicka <jh at suse dot cz>
- To: Pop Sébastian <pop at gauvain dot u-strasbg dot fr>
- Cc: David Edelsohn <dje at watson dot ibm dot com>,Diego Novillo <dnovillo at redhat dot com>, Jan Hubicka <jh at suse dot cz>,gcc-patches at gcc dot gnu dot org
- Date: Fri, 9 May 2003 23:13:35 +0200
- Subject: Re: [tree-ssa] Loop analysis
- References: <20030415135615.GA15937@gauvain.u-strasbg.fr> <20030416225446.GA13440@gauvain.u-strasbg.fr> <200305091641.MAA30920@makai.watson.ibm.com> <20030509165342.GA4515@gauvain.u-strasbg.fr>
> On Fri, May 09, 2003 at 12:41:36PM -0400, David Edelsohn wrote:
> > Why is the loop optimizer inserted before the SSA transformation?
> The loop detector is independent of SSA framework. It uses the CFG representation
> for the initializer, and thus loops should be initialized after the cfg builder.
> The destructor could be moved after the SSA optimizers allowing these to use the
> loop information. However, for the moment, the loop analysis is not used.
While the loop detection is easy, maintaining the infromation up-to-date
is dificult (it is superset of maintaining the dominance tree
information that is still a research topic).
I think it makes more sense to first get SSA, do the
simple (non-loop) optimizations like DCE, cprop, CSE, GVM and then start
to worry about the loops.