[llvm-commits] [llvm] r152753 - in /llvm/trunk/lib/Transforms/Instrumentation: AddressSanitizer.cpp CMakeLists.txt FunctionBlackList.cpp FunctionBlackList.h

Kostya Serebryany kcc at google.com
Wed Mar 14 17:04:22 PDT 2012


On Wed, Mar 14, 2012 at 4:56 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Wed, Mar 14, 2012 at 4:47 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> I was going to suggest to add a function
>> attribute no_thread_safety_analysis (as we did
>> for no_address_safety_analysis).
>>
>
> Makes sense.
>
>
>> clang already knows this attribute (it was added for thread-safety
>> annotations), but does not propagate it to LLVM.
>>
>  ...
>
>> Let me first add the no_thread_safety_analysis attribute to LLVM and then
>> move the blacklist thing to clang.
>>
>
> Awesome, thanks!
>
>
>>  Would you suggest where in clang is the best place?
>>
>
> Hmm, this is a touch tricky.
>
> How big are these files likely to be? <10 entries? <100 entries? <1000
> entries?
>

The largest file we have for valgrind-based tsan has 70 entries, so I would
guess that 100 is an upper bound for a reasonable use case.
Once I finish with the attribute (I need it independently of the blacklist
anyway), I'll send a message to cfe-dev.
And your suggestion makes a lot of sense because the blacklist suddenly
becomes much more testable.
BTW, we may also need to blacklist based on source file names, but I think
it won't make much difference.

--kcc


>
> If <100 entries, I would actually prefer to use the following layering:
>
> Clang Driver: parses flag, loads file, extracts each entry from the file
> into a flag (either separate flags, or more likely, a really long
> comma-separated list of values to a single flag) passed to the CC1 layer.
>
> Clang Frontend: Parses flag into N entries (but doesn't interpret them)
> and stashes those into a side table of the code gen options.
>
> Clang CodeGen: Does whatever is needed to efficiently test each function
> against the blacklist.
>
>
> If we have over 100 entries, this starts to get *really* ugly. In that
> case, we probably need the Driver to parse the option, convert the filename
> to a rooted canonical path, and hand that to the Frontend. Then the
> Frontend will have to open and read the file and setup the list of entries
> for CodeGen. I'm hoping we can have Frontend deal only in terms of flags
> though....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120314/49c0369b/attachment.html>


More information about the llvm-commits mailing list