<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 14, 2012, at 6:08 PM, Kostya Serebryany wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hello, <div><br></div><div>I would like to add one more function attribute: "ThreadSafety".</div><div>Functions with this attribute will be instrumented by run-time thread-safety analysis tools (e.g. with ThreadSanitizer).</div>
<div>This is similar to "AddressSafety" attribute used by AddressSanitizer (and SAFECode?).</div><div><br></div>Clang already has the attribute "__attribute__((no_thread_safety_analysis))" which is used to disable static thread-safety analysis. <div>
<a href="http://clang.llvm.org/docs/LanguageExtensions.html#threadsafety">http://clang.llvm.org/docs/LanguageExtensions.html#threadsafety</a><br></div><div>In a separate change we will teach clang to unset ThreadSafety when no_thread_safety_analysis is present. </div>
<div>(exactly as we do for no_address_safety_analysis and AddressSafety)</div></blockquote><br></div><div>Hi Kostya,</div><div><br></div><div>I'm skeptical of adding LLVM IR function attributes for each instrumentation pass. Have you investigated using module flags metadata to track this information? It is designed to be extensible for these sorts of uses.</div><div><br></div><div><a href="http://llvm.org/docs/LangRef.html#module_flags">http://llvm.org/docs/LangRef.html#module_flags</a></div><div><br></div><div>-Chris</div></body></html>