[PATCH] D67253: clang-misexpect: a standalone tool for verifying the use of __builtin_expect with PGO data

Sun Sep 15 15:15:11 PDT 2019

paulkirth added a comment.

In D67253#1670681 <https://reviews.llvm.org/D67253#1670681>, @lebedev.ri wrote:

> Re concurrency - you had standalone `LLVMContext` for each thread, right?

I believe there was, but this is just whatever happens when libtooling creates and executes a compiler invocation. It seems to me that there is some global state that ends up being shared between threads. I wasn’t able to fully trace the issue, but it at least partly involves the processing of backend options. I believe there is more, that needs to be addressed but this is probably a good place for me to start. Thanks for the suggestion.

> 
> 
> In D67253#1670667 <https://reviews.llvm.org/D67253#1670667>, @paulkirth wrote:
> 
>> In D67253#1670569 <https://reviews.llvm.org/D67253#1670569>, @lebedev.ri wrote:
>>
>> > Layering feels weird here.
>> >  Can this be implemented as/limited to just a
>> >  `run-clang-misexpect.py` wrapper over clang itself?
>> >  That would be best IMHO.
>>
>>
>> I discussed the concurrency issue with some folks who work on libTooling, notably Sam McCall & Dmitri Gribenko. This was the approach they suggested I follow. LibTooling also provides some nice mechanisms for curating compiler options, which is possible, but less than ideal to reimplement in a python script. There are probably more benefits that escape me at the moment, but that was the first one I thought of.
>>
>> Out of curiosity, if the concurrency issue was fixed in the compiler and the python script was removed/deprecated, would you still feel the same way?
> 
> 
> I was actually talking/thinking about the opposite direction, only having the .py wrapper, no standalone tool;
>  so the opposite solution (no .py, only the tool) is tangential/has different direction.

Right, I was asking if you still see this as an issue if the python script wasn’t necessary. I take from this comment that it would not make you feel differently.

I think ultimately keeping the implementation in c++ makes the most sense and can evolve with the rest of libtooling.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67253