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: <tm_gccmail at mail dot kloo dot net>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 29 Sep 2003 13:19:20 -0700 (PDT)
- 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.
For these targets, we would much prefer to assign stack slots at register
allocation time.
Toshi