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

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D67253#1670704 <https://reviews.llvm.org/D67253#1670704>, @paulkirth wrote:

> 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.


Ah yes, i don't think this can work given existing interface.

>> 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.

Right. Not really a blocker, just seems counter-general - there already is a
similar script to run clang-tidy on compilation database, and this script/tool
will have the same purpose - to just ran `clang -Wmisexpect`+profile on compilation database.
It really seems like some generalization is missing.

> 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