[PATCH] D87272: [lld] Buffer writes when composing a single diagnostic

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 9 09:56:30 PDT 2020


MaskRay added a comment.

In D87272#2261876 <https://reviews.llvm.org/D87272#2261876>, @dblaikie wrote:

> In D87272#2261812 <https://reviews.llvm.org/D87272#2261812>, @MaskRay wrote:
>
>> In D87272#2261768 <https://reviews.llvm.org/D87272#2261768>, @dblaikie wrote:
>>
>>> Is performance important in this case? (admittedly, some folks might have builds full of warnings they aren't paying attention to & so they still care about performance then?) Generally the idea with clang/etc is that anything that produces user output (other than the successfully compiled/linked file) doesn't need to be fast (in compile/link-time terms) because it'll take /way/ longer for a user to read and think about the error message than the slight increase in execution time.
>>
>> The nicer thing is that when running under strace/truss, there will be just one write for one diagnostic.
>
> Is that true of many other tools? (I wouldn't've expected it'd be true of clang, for instance - or probably other LLVM utilities) - is it especially helpful?

The motivation was to reduce unneeded ::write calls. Now with jhenderson's suggestion (thanks), this turned to a refactoring. The total number of lines has increased but it looks clearer (the log/warn/error functions don't have to deal with lock_guard, sep, and the order), so I think the end result is not bad.

(The more focused syscall log lines under strace/truss is a very minor benefit)

>> And one can worry less about interleaved output from multiple threads. (I suspect I can remove `std::lock_guard<std::mutex> lock(mu);` but I don't want to take the risk in this patch)
>
> That's what I figured this might be originally about - but if that's already working, I'm not sure there's a need to change? But I don't feel super strongly if the alternative being proposed is especially tidier.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87272



More information about the llvm-commits mailing list