This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa][rfc] plans for nested functions
- From: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>
- To: tm_gccmail at mail dot kloo dot net, Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 30 Sep 2003 13:10:41 +0530
- Subject: 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.