This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa][rfc] plans for nested functions
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Henderson <rth at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Sat, 27 Sep 2003 15:09:26 +0200
- Subject: Re: [tree-ssa][rfc] plans for nested functions
- References: <20030926213651.GC21887@redhat.com>
> 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.
Ineed, I run into this as well. It is nasty beast.
> (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.
We theoretically can inline parent function and clone the inlined
functions as well so we get multiple versions for different frames.
> Now we've got something completely independent from rtl that suffers
> from neither of the discussed problems.
Yes, that sounds like very cool sollution. I am not sure what it will
do to code optimization but in general we should optimize structure
field accesses as well as scalars (we don't currently ehm).
Any idea what to do into non-treeSSA front ends?