This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] PATCH to improve optimization@ssa rewrite time
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- Cc: Daniel Berlin <dberlin at dberlin dot org>,Jason Merrill <jason at redhat dot com>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: 13 May 2003 15:41:50 -0400
- Subject: Re: [tree-ssa] PATCH to improve optimization@ssa rewrite time
- Organization: Red Hat Canada
- References: <C411EE92-8578-11D7-901D-000A95A34564@dberlin.org> <1052854279.5076.78.camel@steven>
On Tue, 2003-05-13 at 15:31, Steven Bosscher wrote:
> Op di 13-05-2003, om 21:26 schreef Daniel Berlin:
> > > This is very useful in conjunction with expression temporaries, which
> > > produce a lot of redundant statements.
> > Actually, as I pointed out to Diego privately, doing all these
> > redundancy eliminations is really screwing up PRE.
> > I've come up with tons of cases where we'd be able to eliminate the
> > entire function if we didn't do these optimizations when going into SSA
> > (because PRE would enable CCP to constant convert everything), but we
> > are left with computations because we did.
> > As soon as PRE is on by default, i'm going to be looking@switching
> > off some of these into-SSA optimizations.
> At what level will PRE be enabled by default, at -O1 or at -O2+?? if
> the latter, would it make sense to keep these little into-ssa enabled at
Unknown at this time. Once all the basic passes are working, we should
start playing that NP game of pass combinations until we find something
satisfactory. It's still too early to know what combination will have
the best effect in the more common cases.
My idea is to at first target SPEC, as it is a reasonably good
approximation. As we get more passes in the framework, we can keep
refining our guesses. But we must not fall in the temptation of making
choices based on micro benchmarks