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

[Jez Ng via Phabricator via llvm-commits]

int3 added a comment.

> 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: D104158 <https://reviews.llvm.org/D104158>

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103977