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.li...@gmail.com> wrote: > On 17 July 2013 20:22, Cary Coutant <ccout...@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
