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

Sriraman Tallam via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 22 16:12:42 PST 2020


tmsriram added a comment.

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

> `.L` prefixed symbols will be discarded by the linker in the default mode (none of --discard-none/--discard-locals/--discard-all is specified).

Aren't these discarded by the assembler itself?

> So if you use `.L` (called PrivateGlobalPrefix in MC), this will work without any linker change (if possible I would hope we just make use of existing conventions instead of adding more linker rules).

So there is some logic to deleting a basic block symbol.  For instance, we will keep a symbol that is discontiguous with the main function as the representative symbol, does that make sense?  We can only delete those symbols that end up contiguous with the main function.

> For the string `__uniq` and `__part`, I am fine with them and actually prefer them if you have measured that they don't cause too mush bloat. The names are clearer than other alternatives like unary coding and special code points (e.g. LLVM IR names make use of `\1`)

Right, we tried unary encoding for our initial prototype and we didnt like the complicated naming.

The thing is full basic block sections will cause size bloats in several ways, especially section table overheads. strtab and symtab bloats is only one aspect of it.  This is why we went with "=list" option for Propeller. Full basic block sections is the generic feature and is very useful for experimenting with various layouts but should be carefully used under size constrained environments.

>> With full basic block sections, the object size bloat from section table outweighs the bloats from strtab and symtab.
>
> `sizeof(Elf64_Shdr) = 64`. A C++ mangled symbol name can be longer than it, but I don't know the average length.




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

https://reviews.llvm.org/D93082



More information about the llvm-commits mailing list