This is the mail archive of the gcc@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: [tree-ssa][rfc] plans for nested functions


> On Fri, 26 Sep 2003, Richard Henderson wrote:
> > This is stuff that was running around my head this morning.
> > I mostly wanted to write this down so that I don't forget...
> > 
> > The problem I'm trying to solve is that, at present, we have
> > ordering issues wrt compilation of nested functions.
> > 
> > (1) We depend heavily on rtl-level state in order to compile 
> >     nested functions.
> > 
> >     A couple of weeks ago I tried to un-nest compilation of nested
> >     functions with cgraph.  It turns out there is so much rtl state
> >     needed that one can not compile the nested function 
> either before
> >     or after the parent -- one *must* compile it *during* 
> the parent.
> > 
> > (2) We cannot inline the parent function, because that would leave
> >     the nested function without a well-defined static-chain frame
> >     to access outer variables.
> > 
> > The solution would be to generate a "virtual frame" directly early
> > in the translation of the parent/nested function pair.  Consider:
> 
> Can we avoid these problems by deferring the frame pointer generation
> until register allocation?
> 
> Generating a "virtual frame" early in code generation is very bad for
> short displacement targets because it prevents stack reordering.

Ordering issues in nested functions have, anyway, prevented 
doing a stack-reorganization because, there is no effective way 
to deal with virtual stack-pseudos of the parent in a child.

Best Regards,
  Naveen Sharma.


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