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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

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

> In D96035#2582232 <https://reviews.llvm.org/D96035#2582232>, @JDevlieghere wrote:
>
>> In D96035#2579270 <https://reviews.llvm.org/D96035#2579270>, @dblaikie wrote:
>>
>>> A non-deterministic behavior is probably not acceptable - it'd certainly be no good at Google if we ever wanted to use this for DWARF linking. Not sure how the Apple folks feel about it for classic dsymutil.
>>
>> Yes, this would be a non-starter.
>
> even if it IS deterministic in --num-threads=1, and is Not deterministic in multi-thread case?
>
> Might changing the ODR uniquing algorithm be a solution then? (That is what I described in some previous message - do not reuse existing type declarations, but generate an artificial compile unit containing the types)? Such artificial compile unit containing the types might be generated in the deterministic way.

I'm not sure why that would necessarily be better/faster - it'd still require two passes, right? One to collect the types, then another to emit the unit with the types and the units referencing that?

If it requires two passes, what about one pass that decides which of the type definitions to keep in the unit that defined them, and which to remove/make a reference to the kept ones? That could then potentially produce the same kind of (& possibly exactly the same) output as is the case today, rather than introducing a new CU?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96035