Re: Unit at time compilation mode II

[Zack Weinberg <zack at codesourcery dot com>]

Jan Hubicka <jh@suse.cz> writes:

>> This is a nifty thing.  Can I suggest you look into using this to
>> disentangle nested-function compilation, so that we never recurse
>> into c_expand_body from the RTL generator?  This would be especially
>> nice to do for C++ where nested classes (containing functions) are
>> part of the official language and used relatively frequently.
>
> Yes, I plan to continue in that direction (in fact I made code so C
> nested functions appears to be compilable independnetly), but I would
> like to make small steps so I didn't boundled that in the initial patch.

Naturally that is the right way to go.  Just wanted to put the idea in
your head, if you hadn't thought of it yourself.

> I would like to switch to callgraph code entirely for C frontend as a
> next step.  I think I can add the logic to not deffer functions when to
> asked to into it and simply remove the function deffering mechanizm from
> C frontend entirely.

Sounds good.  This could make a number of things easier -- stack reorg
in the presence of nested functions, for instance; also bottom-up
inlining, which is difficult to do right now without exponential space
costs.

> For that I need to get obj-C working, that (I hope) will be easy as only
> virtual method table breaks it right now (so I need some way to explain
> that function is needed even when it is not extenrally visible or output
> in data segment as I do right now).

It must be referenced from somewhere... presumably a piece of global
data that isn't itself obviously used?  Perhaps more intelligent
tracking of the content and uses of global data is in order?

zw