Re: Loop optimizer issues

[Geoff Keating <geoffk at geoffk dot org>]

> X-Original-To: geoffk@foam.wonderslug.com
> Date: Wed, 2 Jul 2003 23:46:25 +0200
> From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
> Cc: Geoff Keating <geoffk@geoffk.org>, Diego Novillo <dnovillo@redhat.com>,
>    Richard Henderson <rth@redhat.com>, Jason Merrill <jason@redhat.com>,
>    Jan Hubicka <jh@suse.cz>, Daniel Berlin <dberlin@dberlin.org>,
>    pop@gauvain.u-strasbg.fr, gcc@gcc.gnu.org
> Content-Disposition: inline
> User-Agent: Mutt/1.3.28i
> X-OriginalArrivalTime: 02 Jul 2003 21:46:03.0312 (UTC) FILETIME=[55863B00:01C340E3]
> 
> Hello,
> 
> > >> Does "new loop optimizer" refer to a revision to the RTL loop
> > >> optimizer or a re-write of the loop optimizer in the Tree-SSA
> > >> infrastructure?
> > 
> > Zdenek> rtl one.
> > 
> > >> LIBCALLs should not be present in GIMPLE, should they?
> > 
> > Zdenek> I hope so; this is exactly why I would prefer to handle things there
> > Zdenek> rather than figting it later in rtl.
> > 
> > 	I'm sorry, I'm still confused.  If you are writing an RTL-based
> > loop optimizer, you cannot avoid supporting LIBCALLs.  As long as you are
> > working in the RTL space, you cannot make the simplification that Tree-SSA
> > would allow.
> 
> OK, I will try to be clearer:
> 
> There is part in loop optimizer that deals with LIBCALLs; in particular
> it is able to move them whole out of loops when they are invariant.  The
> things would be much cleaner if we didn't have to care about this, which
> IMHO should be possible -- just do these high-level motions on ast-level
> when they are not represented in this ugly way (and either do only
> simpler pass on rtl, or don't do it there at all, depending on what will
> turn to be more practical).

OK.  So this is a mini-loop-optimiser working on RTL when a loop
optimisation pass has already been run on trees.

In that case, I don't think you need to worry about invariant
libcalls.  It's not clear that you need to worry about invariant moves
at all; the tree-based loop optimiser should have moved all invariant
expressions out of the loop, even addresses of variables (they can
always be moved back in).

-- 
- Geoffrey Keating <geoffk@geoffk.org>