This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop optimizer issues
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Geoff Keating <geoffk at geoffk dot org>,Diego Novillo <dnovillo at redhat dot com>,Richard Henderson <rth at redhat dot com>, Jason Merrill <jason at redhat dot com>,Jan Hubicka <jh at suse dot cz>, Daniel Berlin <dberlin at dberlin dot org>,pop at gauvain dot u-strasbg dot fr, gcc at gcc dot gnu dot org
- Date: Wed, 2 Jul 2003 23:46:25 +0200
- Subject: Re: Loop optimizer issues
- References: <20030702211618.GA26127@atrey.karlin.mff.cuni.cz> <200307022122.RAA25428@makai.watson.ibm.com>
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).
Zdenek