This is the mail archive of the gcc-patches@gcc.gnu.org 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: [c++/cgraph] use cgraph in expand_or_defer_fn


> On Thu, Sep 11, 2003 at 01:54:57AM +0200, Jan Hubicka wrote:
> > The problem I run into was the situation where C++ frontend call
> > cgraph_finalize_function that calls hook for determining inlinability that
> > calls instantiation of the decl that calls another cgraph_finalize_function.
> > I am not quite sure how C++ frontend can keep track of this so the
> > static variable looks like best solution for this particular problem.
> 
> A static function in the c++ front end handles this: function_depth > 1.
> If it isn't happening, then we have a GC problem if nothing else.
> 
> > When loop starts we emit function, emit variable and cgraph code puts
> > comdat function into the pending list, but we don't call
> > cgraph_assemble_pending_functions anymore as C++ fronend does not find
> > any other function needing finalize and terminates the loop
> > not emitting the last variable.
> 
> Indeed, it sounds like a reasonable stop-gap solution until
> all of the queueing is handled in one place.
> 
> Note that I've also found cases in which
> cgraph_assemble_pending_functions itself needs to queue new
> functions -- those seen in the callgraph already, just not
> emitted.

This is supposed to work just fine - during expansion we end up in
cgraph_mark_needed_node that will add node into the queue and
assemble_pending_function will continue processing them until list is
exhausted.  What problem did you run into?

I was also considering adding two lists - one for normal deferred
functions and toher for inline functions while the other will be
proessed only at very end.  We don't win much by compiling these
functions early (as we don't reclaim the memory to alllow inlining) and
we limit the backward inlining opurtunities , but perhaps this is not
worth the trouble.

(if you have some time for explaining, can you tell me what are you
doing to the constructors?  I am getting very curious.  For some time I
was thinking about adidng a machinery for static initializers in C++ -
at the very moment we emit all static initializers we saw independently
on whether variable has been used or not in unit-at-a-time, this is not
good)

Honza


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