This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Tree-profiling branch status
On Mon, 17 May 2004, Jan Hubicka wrote:
> > On Mon, 17 May 2004, Jan Hubicka wrote:
> >
> > > >
> > > > What's going to happen with the tree-ssa-20020619-branch based branches
> > > > now that the tree-ssa branch is closed? I know only of lno and
> > > > tree-profiling, but maybe there are others. I first thought they would
> > > > perhaps be merged into tree-ssa-20020619-branch and development continues
> > > > there.
> > >
> > > The overall plan for tree-profiling branch has been to implemenet the
> > > CFG transparent expansion, inlining and to build CFG just once before
> > > inlining so the profile can be maintained in it.
> > >
> > > The CFG transparent expansion is currently done and I believe that it is
> > > quite stable (it needs testing on more wide variety of platforms).
> > > The only major problem is the fact that mudflap is completely broken but
> > > rewriting it into CFG aware version is not major task I believe.
> > >
> > > The branch also contains fixed branch predictors that can be run early,
> > > GCOV support and the tree-profiling itself.
> > >
> > > The CFG transparent inlining is still being worked on, Stuart will be
> > > able to say more details ;)
> >
> > What do you mean with CFG transparent inlining? You mean we can inline
> > GIMPLE then and do basic optimization before inlining? That would be
> > cool. Anyway, I submitted the leafify patch for inclusion two weeks ago,
>
> Yes, basically the idea is that we can build CFG, do early optimization
> phasses and build the callgraph during analysis phase.
> Then we can decide inlining and do inlinnig already on the gimple form
> with CFG built that would allow profile to be already load, doing
> partial inlining and similar tricks.
>
> I forgot to add Stuart into CC, he has basic patch for this working, but
> I didn't had chance to read it in detail yet.
> Stuart, if you can summarize the status and how much work you think it
> will be needed, it would be cool.
It's that I'd like to get rid of __attribute__((leafify)), and if we can
do some early loop analysis before inlining, we could tune inlining
heuristics (or switch them off) based on loop-nest and predicted/profiled
iteration count. Do you plan to inline in SSA form or just before going
into SSA? Or do gimple -> SSA -> gimple before inlining?
Richard.
--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/