[PATCH] D46874: [MC] - Add .stack_size sections into groups and link them with .text

[George Rimar via Phabricator via llvm-commits]

grimar added a comment.

In https://reviews.llvm.org/D46874#1102694, @jhenderson wrote:

> @grimar, what is the link-time performance of doing this on something with many functions?


I did not yet measure. I can do the benchmark and return with the results.

> Also, I think it would make more sense for the stack sizes section names to be derived from the "parent" section, a bit like relocation sections, so they'd be called something like `.stack_sizes.text._Z3foov` or possibly simply `.stack_sizes._Z3foov`. That way dumping tools can more easily dump the specific individual stack_sizes sections.

Maybe, but renaming is a subject for a different patch.
Also, they linked with a `sh_link` field to their parents already. Dumping tools can use that.
And renaming to something like `.stack_sizes.XXX` would require linker side change to place them into the single output section I think,
as currently they are merged by name, just like other regular sections.



================
Comment at: test/CodeGen/X86/stack-size-section.ll:16
 ; CHECK-NEXT: .Lfunc_begin1:
-; CHECK: .section .stack_sizes,"", at progbits
+; CHECK: .section .stack_sizes,"o", at progbits,.text,unique,1
 ; CHECK-NEXT: .quad .Lfunc_begin1
----------------
jhenderson wrote:
> I might be misunderstanding something here, but I don't think these should be uniqued, i.e. in my opinion, in this case, there should only be one stack_sizes section containing both entries, since there is only one text section.
Probably that would be ideal. I am doing unification unconditionally. I think just everyone use -ffunction-sections. So I am not sure if it worth to
add code to avoid doing unification for that particular case right now. (It just a few lines probably though)

Without doing unification asm produced would contain several declarations of `.section .stack_sizes,"", at progbits` which
are combined into the single section in the object finally. (see original stack-size-section.ll)



https://reviews.llvm.org/D46874