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: Jan Hubicka <jh at suse dot cz>
- Cc: 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>,Mark Mitchell <mark at codesourcery dot com>,Devang Patel <dpatel at apple dot com>, Daniel Berlin <dberlin at dberlin dot org>,David Edelsohn <dje at watson dot ibm dot com>,Dale Johannesen <dalej at apple dot com>, Ron Price <ronp at apple dot com>
- Date: Sat, 26 Jun 2004 12:43:18 +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> <20040626104003.GM4319@kam.mff.cuni.cz>
> > On Fri, 2004-06-25 at 18:08, Jan Hubicka wrote:
> >
> > > However the mainline might be good as well as we already do have
> > > functions gimplified at the time cgraph_analize is called (ie when you
> > > would like to do the analysis).
> > >
> > Really? Then why do we call the gimplifier as one of the tree
> > optimization passes? That makes things easier then. But the bodies are
> We call it only when GIMPLE_BEFORE_INLINING is false, but it is true for
> all existing backends except for fortran, but fortran also gimplify. I
> would vote to drop this code.
Actually looking closer to fortran, it does gimplify only nested
functions, so we re-gimplify just those. Still I don't see any win
in not gimplifying early always. What about changing mainline this way?
Honza