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

[Alexey Lapshin via Phabricator via llvm-commits]

avl added a comment.

> Yeah, having to keep the types in memory is the bit I'm getting at - but yes, it's not all CUs. If they're being unloaded/reloaded though, it might be less clear whether it's so costly to preserve the existing output behavior. Though I don't personally have a problem with creating a synthetic/arbitrary CU to put all the types in either. But other folks (Apple folks with a vested interest in the dsymutil behavior) might disagree.

I see, thanks. I tend to implement such a behavior (creating a synthetic/arbitrary CU to put all the types in either) since I believe that would be the most effective way.
(the practice might show if it is). It would be good to know whether that solution is acceptable/unacceptable before starting implementation. @JDevlieghere @aprantl @friss Would you find "implementation moving types into separate synthetic/arbitrary CU" useful and worth integrating into upstream dsymutil?(if it would show good performance/size results being implemented)

> By "generating resulting DWARF" I guess that has to be buffered in memory? (how could two CUs be written to the final output file at the same time? You wouldn't know where to write to because you wouldn't know how big the previous unit would be if you haven't finished processing it)

Right. The DWARF for each CU is buffered in memory. And after all CUs are processed - They are glued together into the final full resulting DWARF file. That is exactly how this implementation works.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96035