[PATCH] D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units.

[Frederic Riss via Phabricator via llvm-commits]

friss added a comment.

In D96035#2584686 <https://reviews.llvm.org/D96035#2584686>, @avl wrote:

> The scheme implemented in this patch and which might be done with additional compile unit keeping types - visit CU only once and then it might be unloaded from the memory:
>
> 1. the first pass enumerates in a multithreaded manner all object files, all compile units. Each CU is loaded, analyzed for types(there would be created a list of attribute referencing types), emitted. types moved into the artificial CU. unloaded.

How would you guarantee that the artificial CU is always emitted in the same order? It seems like you need to stash the types somewhere, then create a deterministic ordering and then emit it, but I don't remember whether that's doable with LLVM's DIEs (It's been a while since I touched this code).
Conceptually, I think the idea of moving types to a "central" location is valid, it seems semantically equivalent to the kind of debug info we would get with `-gmodules`. Another kind of approach would be to gather enough information to create a dependency graph of CUs and then orchestrate parallel processing according to this. Even if this would limit the parallelism at the beginning of a link, I think it's very hard to intuitively figure out whether it would perform worse than the approach above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96035