This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Group static constructors and destructors in specific subsections
- From: Martin LiÅka <marxin dot liska at gmail dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Ian Lance Taylor <iant at google dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>, iains at gcc dot gnu dot org, Taras Glek <tglek at mozilla dot com>
- Date: Mon, 18 Nov 2013 08:38:32 +0100
- Subject: Re: Group static constructors and destructors in specific subsections
- Authentication-results: sourceware.org; auth=none
- References: <20101014203817 dot GB15487 at kam dot mff dot cuni dot cz> <AANLkTikm11+0tAMb=58MXWP8_DHLNXfBgGnZZ2o2QCw6 at mail dot gmail dot com> <CAHACq4oP_zqSE2dNNfXdui-YLoXPsQNE+BtA+cf_BQgese3AQg at mail dot gmail dot com> <20130715180530 dot GA1985 at kam dot mff dot cuni dot cz> <CAKOQZ8w96UeFYv9dyREhwz2XGcDDkq6vLjVadOzHmmykAc+KHg at mail dot gmail dot com> <20130715181846 dot GB1985 at kam dot mff dot cuni dot cz> <CAKOQZ8wSTtjnwGOAU=LEWXu42_q-A4ET54b8M0WZYXwYwnu6Dg at mail dot gmail dot com> <20130717013130 dot GA30913 at kam dot mff dot cuni dot cz> <CAHACq4omThM=5xyCrgezzbk0+Lc1zNd-muCB0uPbrYeNWVxNiA at mail dot gmail dot com> <CAObPJ3P0GvYWvpZ5cEOVTCTpq2a+dfxb8iZbZxt++mVVUm5oRQ at mail dot gmail dot com>
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,
Martin
On 20 July 2013 14:58, Martin LiÅka <marxin.liska@gmail.com> wrote:
> On 17 July 2013 20:22, Cary Coutant <ccoutant@google.com> 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