Re: Deal with local static same way as we deal with global static for IPA

[Jan Hubicka <jh at suse dot cz>]

> > On Tue, Jun 07, 2005 at 10:11:59PM +0200, Jan Hubicka wrote:
> > > ! 	/* FIXME: tree-inline.c duplicates static declarations during copying
> > > ! 	   BIND_EXPR_VARS list (so they can be chained by TREE_CHAIN) while
> > > ! 	   other occurences are still shared (as static variables
> > > ! 	   are shared), so we need to look for the origin here.  Kill it
> > > ! 	   once this is cleaned up.  */
> > > ! 	cgraph_varpool_finalize_decl (DECL_ORIGIN (decl));
> > 
> > I think I'd rather you fix this first, rather than put this hack in.
> 
> I don't see how to do that easilly - the BIND_EXPRs are linked via
> TREE_CHAIN pointers and we need the local static in two BIND_EXPRs at
> once, but we have only one link pointer.
> One sollution I saw was to make C++ frontend lower function before
> clonning (so we don't clone at generic level at all).  I got half way
> throught my way across C++ frontend, I might try to finish it if this
> plan sounds sane, but I would preffer doing so incrementally.
OK and the point where I stopped is that C++ frontend currently produce
some code in DECL_SAVED_TREE while constructing the clone (apparently
initializing the parameters that differ from original) and then it
appends the duplicated body.
Now we have the initializers in generic and the body in gimple that
means that either C++ frontend would have to produce gimple directly
when constructing the initializers or gimplify the partical function
body before pasting in the inlined body.  Since I would like to keep
frontend's generic and backend's gimple separated so generic or gimple
memory representation might change at some time, this looks like nasty
obstackle.
What sounds like resonable way to solve this?  (assuming that this is
resonable plan at first place ;), but killing the generic code from
tree-inline is pretty desirable cleanup....)
> 
> Honza
> > 
> > The rest of it seems ok.
> > 
> > 
> > r~