This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop optimizer issues
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, Jason Merrill <jason at redhat dot com>, pop at gauvain dot u-strasbg dot fr, Jan Hubicka <jh at suse dot cz>
- Date: Mon, 2 Jun 2003 17:47:04 -0400 (EDT)
- Subject: Re: Loop optimizer issues
- References: <20030530183552.GA27110@atrey.karlin.mff.cuni.cz><1054585449.9789.146.camel@frodo.toronto.redhat.com>
On Mon, 2 Jun 2003, Diego Novillo wrote:
> On Fri, 2003-05-30 at 14:35, Zdenek Dvorak wrote:
>
> > The process of merging of the loop optimizer work I am currently doing
> > on rtlopt branch. I am quite sure that I won't be able to get it to
> > reasonable state for 3.4. I would however like to reuse some parts of
> > this work on tree-ssa. Would it be feasible to merge this work from
> > rtlopt branch to tree-ssa branch once it is in sufficiently stabilized
> > state (in about a month or so)?
> >
> I think that's a good idea. However, I would try to avoid introducing
> too many instabilities to the branch. Can the code be disabled by
> default?
>
> > What parts do we want to do on ast level and what on rtl level?
> > The optimizations I would like to see on rtl level:
> >
> Hard to say without some experimentation. Dan has volunteered to
> compare several compilers that he's familiar with. That looks like a
> reasonable starting point.
>
> > And finally, who will do it? I of course volunteer for anything of the
> >
> Agreed. I had thought of doing infrastructure bits like induction
> variable detection and what-not. Other than that I think that we could
> take ideas from what other compilers do and let people start
> implementing whatever tickles their fancy.
>
> To avoid duplicate effort, let's just raise our hand whenever we are
> going to get started with something. The initial list that I had in
> mind (at the tree level) includes:
>
> Induction variable detection
This may not be necessary depending on the array dependency info
mechanism.
As for the LFTR part of IVD that usually happens, it's an SSAPRE strength
reduction extension, but i don't quite have a handle on implementing it yet.
> Array dependency information
> Unswitching
> Peeling
> Interchange
> Fusion
> Fission
>
> I volunteer to collect suggestions and keep them in the TODO section of
> the project page together with whoever is working on it. If there are
> two proposals for the same analysis/optimization but with different
> approaches, we may want to implement both and then decide which one we
> like best.
>
> Since we are just getting started, having a strict separation of tasks
> doesn't strike as the best approach. Unless someone has direct
> experience with implementing loop optimizers at two levels of IL,
I have experience implementing optimizations at two levels of IL.
Remember the original tree/RTL SSA optimizer that used function pointers?
Not that it was pretty, but ...
:)