[PATCH] D93082: Append ".__part.<ID>" to all basic block section symbols.

[Sriraman Tallam via Phabricator via llvm-commits]

tmsriram added a comment.

In D93082#2469132 <https://reviews.llvm.org/D93082#2469132>, @MaskRay wrote:

>> b) The current basic block naming just adds a ".N" to the symbol name where N is some integer. This collides with how clang creates __cxx_global_var_init.N. clang creates these symbol names to call constructor functions and basic block symbol naming should not use the same style.
>
> This reason alone is not sufficient I guess. `__part.N` greatly increases .strtab usage. Are there other benefits?

There are exactly two reasons to do this:

1. The simple naming collides with __cxx_global_var_init.N naming, which is a show stopper.
2. External tools need to understand symbol names such as these for profile attribution.   D89617 <https://reviews.llvm.org/D89617> did that unique internal linkage symbols by adding the __uniq suffix.  This adds the __part suffix.

Having said that, let's come to the part of .strtab bloats.  Yes, we are aware of that and have gone to great lengths to minimize this for Propeller:

- For e.g. -fbasic-block-sections=labels uses a special section to store these symbols without bloating strtab and symtab
- Propeller uses -fbasic-block-sections=list to selectively create sections which reduces strtab bloat and section  table bloat significantly (close to zero for intra-procedural re-ordering)

With full basic block sections, the object size bloat from section table outweighs the bloats from strtab and symtab.  However, please note that this is only the object file sizes.  In the final binary, after the reordering has taken place, the unwanted symbols (those that are contiguous to the main function) will be deleted (patch pending) and hence this bloats will not carry over to the final binary size. Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93082/new/

https://reviews.llvm.org/D93082