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

Jonas Devlieghere via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 5 16:40:00 PDT 2022


JDevlieghere added a comment.

In D96035#3291217 <https://reviews.llvm.org/D96035#3291217>, @dblaikie wrote:

>>> Does anyone cares about single thread execution time? I personally don't.
>>
>> If we do not then things are easier :-)
>
> I think @JDevlieghere and @aprantl probably care about it just from a regression perspective - but I could be wrong. (I thought they'd expressed some concerns about that in this/other reviews previously).
>
> Apple folks ^ have you got a sense of if/how much of a single threaded regression you'd want to accept in this work, for some multithreaded gains?

If it's purely time, I don't care too much about single threaded performance. When the lookForDiesToKeep algorithm was recursive we would occasionally run out of stack space because std::threads (underlying LLVM's thread pool) have a ridiculously small stack and no way to increase it. So we had this workaround in place for a while that if you specified -j1 it would not avoid the thread pool altogether. But since I converted that algorithm to a work list/state machine that's not really a concern anymore. The thing I did express concerns about what an earlier revision of this change that caused non-determinism in multithreaded mode which is not really negotiable but IIUC that's no longer the case with the current patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96035



More information about the llvm-commits mailing list