[PATCH] D103977: [lld-macho][nfc] Move liveness-tracking fields into ConcatInputSection

[Nico Weber via Phabricator via llvm-commits]

thakis added a comment.

In D103977#2814584 <https://reviews.llvm.org/D103977#2814584>, @int3 wrote:

>> But overall, it feels like things get a lot more complicated because we're not creating real InputSections for each literal in literal sections.
>
> I agree, it's quite unfortunate...
>
>> Are there so many more literals than normal symboled inputsections? What's the memory / perf hit from just having normal InputSections for each literal?
>
> Good questions! For chromium_framework, here are the relative counts of literals and subsections before deduplication (generated via D104158 <https://reviews.llvm.org/D104158>):
>
>   word literals: 145224 (8%)
>   cstring literals: 353031 (20%)
>   subsections: 1260720 (72%)
>
> So actual subsections are still by far the largest, but cstrings take up a sizable chunk regardless. I also hacked up a diff that creates one InputSection per string, and even without doing dedup, it's already slower: D104159 <https://reviews.llvm.org/D104159>
>
> The remaining question is... could we trim InputSection's size and close this performance gap? There are definitely opportunities here (e.g. we could replace `name`, `segname`, and `flags` with a pointer to the original `section_64` header.) But there's still quite a number of other fields that I doubt can be removed. So while this is not a watertight analysis, I think it's enough to make a case for landing this architectural change.

Thanks for collecting this data!

The ELF's port's -fdata-sections behavior means it has one actual section per string, right?

Since most sections are "normal" subsection sections, we kind of need to optimize sections anyways. But we can do that first and then reconsider if we need the special cases for literals.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103977