This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-profiling-branch PATCH] Function cloning + IPCP extension
- From: Jan Hubicka <jh at suse dot cz>
- To: Razya Ladelsky <RAZYA at il dot ibm dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, Ayal Zaks <ZAKS at il dot ibm dot com>,gcc-patches at gcc dot gnu dot org, hubicka at ucw dot cz,Mircea Namolaru <NAMOLARU at il dot ibm dot com>, stevenb at suse dot de
- Date: Mon, 30 Aug 2004 16:11:51 +0200
- Subject: Re: [tree-profiling-branch PATCH] Function cloning + IPCP extension
- References: <20040829135105.GB21587@kam.mff.cuni.cz> <OF2D1A7FBC.0538A8B5-ONC2256F00.00474B79-C2256F00.00475640@il.ibm.com>
> Hello,
>
> > It looks like we do have two different mechanisms to keep function body
> > alive until all clones are processed. For inline clones we use the
> > linked list via next_clone and take advantage of fact that all of them
> > do have same DECL node and same hash slot, while for new clones we use
> > reference counting.
> >
>
> Since a versioned node has a different FUNCTION_DECL than the original
> node,
> using the same mechanism for keeping the clones seems to be complicated.
It should not be too dificult - there are very few places in the code
that actually needs to worry about the decs themselves. Only reason why
they do so is that they use the decl hashtable to look up beggining of
the list of clones that can be easilly avoided by using the orig
pointer. I used the hashtable just to conserve memory until there is
real need to add extra pointers around.
>
>
> > +
> > + /* Remove unreachable nodes. */
> > + void
> > + cgraph_unreachable_nodes_elimination (void)
> >
> > how this is different from cgraph_remove_unreachable_nodes we have
> > already?
>
> It seems that calling cgraph_remove_unreachable_nodes
> should be done only after the inlining decisions had been made
> (as documented in top of the function).
Hmm, it was written to be used after inline decisions has been made as
parts of cgraph may become unreachable, but it should do the job
anytime - all it does is to walk the cgraph datastructure and elliminate
everything unvisited.
It is slightly more complicated than your code just because it is trying
to be aggressive about weird semantics of extern inline functions, but
that should not be an issue for you.
Honza
>
> Thanks,
> Revital and Razya