Re: struct function cleanup part I

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka wrote:
> 
> >For thread safety I can think of two possible basic approaches: making
> >the "context" variables thread local, in that case
> >cfun/current_function_decl/rtl would be all thread local storage and
> >nothing significantdly changes with current code (ie we still reffer
> >directly to the rtl structure).
> >
> >Or we add parameter passing context.  Then for GIMPLE world it might be
> >cfun, for RTL world it might be the new "rtl" structure or cfun
> >structure well.
> 
> We don't want these things to be thread-local.  We'll have some number 
> of worker threads, but each one may work on multiple functions, possibly 
> interleaving things in some way.

If we don't want to go for the thread local storage model, but pass
information about processed object everywhere, it would make a lot sense
to me to have separate "rtl function" (that I am trying to accomplish
with struct rtl) and "gimple function" (that I would like to have struct
function for) objects both referencing the original function object (ie
tree representation).

RTL world would operate on rtl function objects and gimple world on the
gimple function objects.  It is bit convenient to tie gimple with
struct function since we turn whole unit into gimple representation and
move gimple from one function to another.  We don't want to do this on
RTL even if we want to process multiple RTL function bodies for
paralelism.

The combined cfun having everything was problem that adding new RTL
fields leads to increase memory consumption and adding new pointers to
nested substructures just increase amount of pointers we need to walk.
This is what leaded me to break it out (in addition to LTO project I
would like to push the hot/cold emitting patches that need extra global
var otherwise too).  I would like to put there other RTL status
bookkeeping, like reload_completed too.
> 
> The basic principle I am trying to espouse is that designing with 
> objects allows lets you reuse in different ways later.  Right now, it 
> may seem inconceivable that we want to have two active RTL compilations 
> at once in the same thread -- but we don't that will always be true. 
> Having some kind of indirection gives us more choices.  The only things 
> that should be global are things of which there really can be only one.
> 
> So, I like your second plan better.
> 
> >I can, of course, add "get_rtl_data (cfun) at each apperance of "rtl.".
> >To me it seems to make code noticeably less streamlined with just little
> >saving of effort for possible future threaded GCC patch that might take
> >this approach of implementation.
> 
> I agree that it's not too hard to do a sed run later.  But, making 
> things global encourages us to start building global dependencies. 
> Associating the RTL (which is logically per-function information) with 
> the function gives us a lot better modularity.

If "passing around" (ie keeping room to be passed around) cfun object
rather than rtl object is prefferable, I think I would suggest using
simple rtl(cfun) accestor for brevity.  I am still holding the followup
patch that does more verbose replacements, so before that I would
replace current rtl. occurences by rtl(cfun)-> and update the second
patch before applying.

Another option that would make sense to me is to simply immitate that
"rtl" is pointer, that is use rtl-> everywhere expecing that later RTL
functions will start passing it around instead of the cfun pointer.
Since I think it is benefical for now for compiler to see that there is
single global rtl, I would propose something like renaming current rtl
to x_rtl and adding accestor macro #define rtl (&x_rtl)

Whatever you preffer more.  I would probably lean more to second option
since it would make it more obvious what we operate on even if we would
need to introduce some way to get back from "cfg object" to "rtl object"
or "gimple object" to implement our abstractized CFG manipulation ABI
(such as edge redirection) that would take pointer to the cfg object
in this scheme where might simply operate on cfun in the first scheme.

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713