This is the mail archive of the
mailing list for the GCC project.
Re: proposal for compilation unil wide alias analyis
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc at gcc dot gnu dot org, Stuart Hastings <stuart at apple dot com>,Geoffrey Keating <geoffk at apple dot com>,Mark Mitchell <mark at codesourcery dot com>,Devang Patel <dpatel at apple dot com>,"Novillo, Diego" <dnovillo at redhat dot com>,"Berlin, Daniel" <dberlin at dberlin dot org>,"Edelsohn, David" <dje at watson dot ibm dot com>,Dale Johannesen <dalej at apple dot com>, Ron Price <ronp at apple dot com>
- Date: Fri, 25 Jun 2004 18:23:13 -0400
- Subject: Re: proposal for compilation unil wide alias analyis
- References: <40DB07B2.firstname.lastname@example.org> <20040625220852.GA17010@kam.mff.cuni.cz>
I will look into this, and indeed I would rather work off the main line
than this line.
However what you say here seems to confict with what I was told by others.
I was told by diego that the main line built the call graph over parse
trees. I was told by stuart hastings that if I wanted to do my work
over gimplified functions, I would either have to do it myself or use
this branch. In fact I only discovered this branch because stuart saw a
note I sent to his (an my) manager, Ron Price.
I have just started looking at the profiling code to see where I want to
attach my hooks. When I find what I want, I will go back and see if the
same code exists on the main branch. As far actually using the
information, I would not expect to touch files that you have modified.
Jan Hubicka wrote:
However, Stuart Hastings of Apple appears to be close to having a
working branch of the compiler that gimplifies an entire compilation
unit. This code is on the tree-profile-branch and was done in order
to support better inlining.
I have nothing against having this cahnges directly on the
tree-profiling-branch assuming that they won't end up touching very many
different places of compiler making the patch separation dificult later
(I won't expect so here).
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). Only frontend going generic right now
is fortran and it gimplify early in order to get functions un-nested.
For context insensitive points to this should be all you need to get
functions analyzed easilly.
Also I was under impression that doing basic IPA alias analysis should
be just question of hooking Daniel's points to analyzers into
cgraph code (ideally we would like to do points-to before cgraph is
build so we can do sane estimations on indirect calls - not the overly
pesimistic stuff we do right now) and our existing RTL/tree alias
analyziers. I believe part (most?) of this should be done already.
I am on the trip till 30th, but I will definitly look deeper into this