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: Group static constructors and destructors in specific subsections

Dear Cary,
   I've been merging my patches to GCC mainline and I would really
appreciate new section naming convention that was suggested by you in
the previous post. Is there any progress in implementation? Should I
participate in this change and write a patch that will introduce this
new section model?

Thank you,

On 20 July 2013 14:58, Martin LiÅka <> wrote:
> On 17 July 2013 20:22, Cary Coutant <> wrote:
>>>> > Yep, the problem is where to produce the section ordering file.
>>>> > The scheme is as follows:
>>>> >   - with -fprofile-generate instrument every function entry point and record
>>>> >     time of first and last invocation of the functoin
>>>> >   - At compile time we take functions that are executed during the startup
>>>> >     and we want to order them in the increasing order of the first invocation
>>>> >     time measured at FDO time. So we know the relative position of given function
>>>> >     in the program, but not the complette function order.
>>>> Perhaps I misunderstand, but you can use --section-ordering-file
>>>> without knowing the complete function ordering.  Just specify the
>>>> functions you care about.
>>> The thing is that when compiling given object file, you know only functions in
>>> that object file, so you can not produce full --section-ordering-file.  We
>>> would need a tool colleting the partial orders from all objects to single file
>>> that I think may be just done in linker.
>> How granular a solution do you need? If you need something fine-grain,
>> like microseconds since startup, we'd also need some way of ensuring
>> that all compilation units are using the same scale. What if someone
>> else wants to order by execution count instead? We could do something
>> coarse-grain by adding a few more "buckets" after "unlikely", "exit",
>> "startup", and "hot", but you probably would need to see the whole
>> program before you could translate something like time-since-startup
>> into a bucket.
> I cooperate on function reordering with Jan, we are primary motivated
> to reorder all functions called during startup. I did small
> observation, e.g. Inkscape has about 14K function, where 2.5K (~20%)
> are called during startup. Apart from that, we would also like to
> reorder the rest of functions that are not in the first collection of
> functions (e.g. according to edge call graph profile). Thus, it would
> be nice we can de facto set up an order for all functions.
>> In another old thread, I suggested modifying the section naming
>> convention to remove the ambiguity between a function named "unlikely"
>> compiled with -ffunction-sections, and an arbitrary function placed
>> into the "unlikely" bucket. Namely, instead of using
>> ".text.function_name" and ".text.bucket", we combine these into
>> ".text.bucket.function_name". Without -ffunction-sections, we'd just
>> have ".text.bucket" like we do today, but with -ffunction-sections,
>> we'd have ".text..function_name" in the case where there is no bucket.
>> In order to distinguish between old and new conventions, I'd amend
>> that suggestion to use a different set of delimiters -- perhaps
>> ".text[bucket](function_name)". That at least makes it more obvious
>> that the input section goes into an output section named ".text", and
>> we can have a general rule rather than the collection of special cases
>> we have now.
>> To support your use case, we could allow, in addition to the four
>> buckets we already have defined, numeric buckets ranging from, say, 0
>> to 99999. You could map whatever ordering criterion you want to use
>> into that range, and the linker would order the text sections by
>> bucket, placing the numbered buckets after "hot" and before all the
>> unbucketed sections. I might further suggest moving "unlikely" to the
>> end, after all the unbucketed sections.
> I would enhance the capacity of such ranging buckets (f.e. Firefox
> does have more than 10^5 functions).
>> (I can't believe I'm suggesting this -- I don't like the increasing
>> effect that section names have on the linker behavior, but I don't
>> think we really have any better options in ELF.)
>> As an aside, is there any reason why the function name must appear in
>> the section name when we use -ffunction-sections? ELF doesn't require
>> sections to have unique names, so they could all be named ".text". We
>> could do section reordering based on the symbol names rather than the
>> section names, so it's not necessary for reordering. As far as I can
>> tell, it's just an assembler limitation, which we could fix by
>> modifying the syntax of the .section directive to allow both an
>> assembler name and a linker name. All those function names just bloat
>> the section string table for no good reason.
> It's not necessary to produce function sections, but it's question for
> Jan and another compiler developers, how could symbol renaming help
> with function ordering?
> Martin
>> -cary

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