This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: proposal for compilation unil wide alias analyis

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]