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: Jan Hubicka <jh at suse dot cz>, David Edelsohn <dje at watson dot ibm dot com>,Zack Weinberg <zack at codesourcery dot com>,Diego Novillo <dnovillo at redhat dot com>,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: Tue, 29 Jun 2004 06:20:05 +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> <20040628145446.GB17010@kam.mff.cuni.cz> <40E0360E.4060906@codesourcery.com>
> Jan Hubicka wrote:
>
> >>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?)
> >
> >
> If the results were that good, is there any reason not to check in this
> change? Perhaps you could post it and get people to evaluate it on some
> other code. If we're seeing those kinds of improvements, we definitely
> want it!
It is checked in already ;) (so we basically go into low gimple and
trees always)
Honza
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com
>