This is the mail archive of the 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

> 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?

> r~

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