<br><br><div class="gmail_quote">On Wed, Mar 14, 2012 at 4:56 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Wed, Mar 14, 2012 at 4:47 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>I was going to suggest to add a function attribute no_thread_safety_analysis (as we did for no_address_safety_analysis).</div></blockquote><div><br></div></div><div>Makes sense.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>clang already knows this attribute (it was added for thread-safety annotations), but does not propagate it to LLVM.</div><div><div></div></div></blockquote></div><div> ...</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div>Let me first add the no_thread_safety_analysis attribute to LLVM and then move the blacklist thing to clang. <br></div></div></blockquote><div><br></div></div><div>Awesome, thanks!</div><div class="im"><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div></div>
<div>Would you suggest where in clang is the best place? </div></blockquote></div></div><br><div>Hmm, this is a touch tricky.</div><div><br></div><div>How big are these files likely to be? <10 entries? <100 entries? <1000 entries?</div>
</blockquote><div><br></div><div>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. </div><div>Once I finish with the attribute (I need it independently of the blacklist anyway), I'll send a message to cfe-dev. </div>
<div>And your suggestion makes a lot of sense because the blacklist suddenly becomes much more testable. </div><div>BTW, we may also need to blacklist based on source file names, but I think it won't make much difference. </div>
<div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>If <100 entries, I would actually prefer to use the following layering:</div><div><br></div><div>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.</div>

<div><br></div><div>Clang Frontend: Parses flag into N entries (but doesn't interpret them) and stashes those into a side table of the code gen options.</div><div><br></div><div>Clang CodeGen: Does whatever is needed to efficiently test each function against the blacklist.</div>

<div><br></div><div><br></div><div>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....</div>

</blockquote></div><br>