[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