This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposal for compilation unil wide alias analyis
- From: Jan Hubicka <jh at suse dot cz>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: David Edelsohn <dje at watson dot ibm dot com>,Zack Weinberg <zack at codesourcery dot com>,Diego Novillo <dnovillo at redhat dot com>, Jan Hubicka <jh at suse dot cz>,Ken Zadeck <zadeck at naturalbridge dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>,Stuart Hastings <stuart at apple dot com>, Geoff Keating <geoffk at apple dot com>,Devang Patel <dpatel at apple dot com>, Daniel Berlin <dberlin at dberlin dot org>,Dale Johannesen <dalej at apple dot com>, Ron Price <ronp at apple dot com>
- Date: Mon, 28 Jun 2004 16:54:46 +0200
- Subject: Re: proposal for compilation unil wide alias analyis
- References: <40DB07B2.1090108@naturalbridge.com> <20040625220852.GA17010@kam.mff.cuni.cz> <1088209471.17853.55.camel@localhost.localdomain> <874qoy6rhn.fsf@taltos.codesourcery.com> <40DDD35B.6010702@codesourcery.com> <200406262254.i5QMsTa26700@makai.watson.ibm.com> <40DE2A61.5050706@codesourcery.com>
> David Edelsohn wrote:
>
> >>>>>>Mark Mitchell writes:
> >>>>>>
> >>>>>>
> >
> >Mark> The Laffer curve argument (we can remove so much code in the
> >optimizers Mark> so quickly that generating the code will actually be
> >faster) seems to me Mark> like it is one that should be proven
> >experimentally before we commit to it.
> >
> > The argument that running some simple optimizations at -O0
> >decreases the amount of intermediate code and improves the compilation
> >speed of a compiler is proven experimentally by the IBM XLC Compiler.
> >
> >
> >That is exactly the technique that XLC uses, with extremely careful,
> >empirical tests of which fine-grained optimizations should be enabled to
> >produce the best compilation performance[1]. We need to test that such a
> >technique has a beneficial effect on GCC, but there is no question that
> >the technique can be effective.
> >
> >
> Agreed on both points -- both that it can be effective, and that we need
> to demonstrate that it works with GCC. I think we want to avoid
> committing to (say) making the tree->rtl expanders accept only SSA-form
> GIMPLE until we can demonstrate that it will be a compile-time win to do so.
Only experiment in this direction I made so far was to build CFG at -O0
unconditionally and do tree cleanup_cfg before expanding (this was
needed for the CFG transparent RTL expansion task). The results were
about 4% speedup on combine.c compilation times. The speedup ranged from
noise to 8% on real world testcases I tested even tought the tree
cleanup_cfg is surprisingly expensive (ie doing 7 RTL cleanups accounts
together 1/4th of time of the single tree cleanup, any idea why?)
I believe that moving expanders from generic to low gimple will be
performance win just by simplifying the whole task and reducing the
abstraction penalty we pay right now.
I don't feel 100% convinced about SSA, but it might be easy experiment
now on th emainline.
Honza
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com
>