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: Mark Mitchell <mark at codesourcery dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: 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: Mon, 28 Jun 2004 08:15:26 -0700
- Subject: Re: proposal for compilation unil wide alias analyis
- Organization: CodeSourcery, LLC
- 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>
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!
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com