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

[Chandler Carruth]

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?

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/b76abcd3/attachment.html>