Re: [PATCH 0/2] Proof-of-concept towards removal of the "cfun" global

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, May 27, 2013 at 3:41 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>
>> I think that was one reason crtl was introduced ... to avoid an indirection
>> through cfun.
>
> Main reason why I introduced crtl was to get struct function less bloated.
> RTL data live for only one function body at a time. It is useless to store them
> in a datastructure that is allocated at parsing time and freed at very end of
> compilation.
>
> I never did really serious analysis on performance implications of having crtl
> a static viarable or pointer or pointer from cfun.  With current threading
> efforts, I guess we can either make RTL optimizers to have their own RTL
> context (i.e. crtl pointer passed everywhere) or just have crtl pointer in cfun
> (and get extra indirection + waste 8 bytes on every function body).
>>
>> I indeed welcome the effort to make all 'cfun' uses explicit.  Even more welcome
>> is reducing the number of 'cfun' references ;)  Like giving all gimple/rtl pass
>> execute () / gate () functions a struct function argument (or even
>> better abstract
>> that so we can add more context transparently later, like dump_file /
>> dump_flags).
>
> Yep. One of issues is that for IPA/RTL/Gimple passes the notion of context is
> always slightly different and not exactly matching the purpose of a function
> in the IL/symbol table.

Yeah, well.  The idea still holds that it would be nice to annotate passes
that are "safe" (do not reference cfun in any way) and NULL cfun from
the pass manager for that passes.  Of course IPA passes still access the
global symtab_nodes array - a bit to go until one compiler instance can
process multiple TUs at once ;)

Richard.

> Honza