[cfe-commits] please review: adding module-level metadata for ThreadSanitizer

[Kostya Serebryany]

Ping?

On Wed, Sep 5, 2012 at 10:33 AM, Kostya Serebryany <kcc at google.com> wrote:

> Bill,
>
> Did you continue this discussion recently?
> Any suggestions?
>
> Thanks,
>
> --kcc
>
>
> On Thu, Aug 23, 2012 at 4:50 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> "Encoding Compile Flags into the IR"?
>> Yes, that's the same problem.
>> Great! I can wait.
>>
>> --kcc
>>
>> On Wed, Aug 22, 2012 at 9:55 PM, Eric Christopher <echristo at apple.com>wrote:
>>
>>>
>>> On Aug 22, 2012, at 12:20 AM, Kostya Serebryany <kcc at google.com> wrote:
>>>
>>> > Hello,
>>> >
>>> > I'd like to resurrect an old discussion: how to selectively disable
>>> ThreadSanitizer (or AddressSanitizer, etc) instrumentation
>>> > for particular functions.
>>> > For AddressSanitizer we currently use a function attribute
>>> "AddressSafety" (if it is not set, instrumentation does not happen),
>>> > but Chris doesn't like this idea (attributes are a scarce resource)
>>> and he suggested to use module-level metadata instead of an attribute.
>>> >
>>> > The attached clang patch adds such metadata node for all functions
>>> when -fthread-sanitizer is given.
>>> > If that is what we want, I'll gradually change AddressSanitizer to use
>>> similar approach and will kill the "AddressSafety" attribute.
>>> >
>>> > BTW, the code looks like this:
>>> >   llvm::Value *Fn[] = { F }; ...
>>> >   llvm::MDNode::get(VMContext, Fn);
>>> > Do we want this code to look like
>>> >   llvm::MDNode::get(VMContext, F);
>>> > (i.e. to add more llvm::MDNode::get() methods)?
>>>
>>> Bill has been working on something similar for command line options and
>>> LTO. There's still been some chatting about it, but Bill's planning on
>>> updating the list in the next few days with what's going on if waiting a
>>> bit is ok?
>>>
>>> -eric
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121002/49daa4d7/attachment.html>