Re: Group static constructors and destructors in specific subsections

[Jan Hubicka <hubicka at ucw dot cz>]

> On 10/14/2010 02:11 PM, Jan Hubicka wrote:
> >> We have a nicely modular section object.  It would seem
> >> we should make more use of that.
> > 
> > Hmm, you got me ;) I am not quite sure what do you suggest.
> > The hooks exists mostly so darwin can redefine them and hp-ux can disable them
> > to avoid linker bug.  I guess HPUX could go with just disabling the function
> > reordering flag, what darwin should do?
> 
> Default would do something very much like the
> unlikely_text_section function.
> 
> Darwin likewise, except with their funny names.
> 
> Hpux would simply return text_section.

OK, so we will have target hooks that do return function pointers (instead of
current function names) for function returning section object.  We will defult
them to return existing unlikely_text_section function pointer for
UNLIKELY_EXECUTED.  For HOT/STARTUP and TEXT we will have newly born functions
hot_text_section, startup_text_section and exit_text_section?

>From where the actual names will be fed?  Every target (i.e. rs6000 and i386
darwin ;) that requires different section names will need to define 4
equivalents of unlikely_text_section? 

It always seemed to me that unlikely_text_section complexity comes from fact
that it attempts to handle functions with names sections (especially ones
supplied by -ffunction-sections) so function splitting works.  We don't do
function splitting into the hot/startup nor exit subsections.  Always the whole
thing goes there or nothing, so for functions with named sections we don't want
to do this optimization at all.

Also choose_function_section will need reorg to somehow not operate on section
names but section structures.  What should be interface there?

I must say it is bit escaping me how this helps to make things more modular,
but I will look a bit more into the code.

Honza

> 
> 
> r~