<br><br><div class="gmail_quote">On Mon, Mar 19, 2012 at 4:30 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote:</div><br><blockquote type="cite">Hello, <div><br></div><div>While instrumenting LLVM IR in ThreadSanitizer (race detector), I need to distinguish between a store to vtable pointer (vptr) and any other regular store. </div>
<div>This special treatment should be limited to class DTORs, so I should also know when a function is a DTOR. </div>
<div>Rationale: need to distinguish benign and harmful races on vptr (<a href="http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr" target="_blank">http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr</a>). </div>

<div><br></div><div>Currently, I can figure out when a function is a DTOR and when a store touches vptr by analyzing mangled names.</div><div>_ZN1BD1Ev=="B::~B()"<br>_ZTV1B=="vtable for B"</div><div><br>

</div><div><div>define linkonce_odr void @_ZN1BD1Ev(%struct.B* %this) unnamed_addr nounwind uwtable align 2 {</div><div>entry:</div><div>  ....</div><div>  store i32 (...)** bitcast (i8** getelementptr inbounds ([5 x i8*]* @_ZTV1B, i64 0, i64 2) to i32 (...)**), i32 (...)*** %0, align 8</div>

</div><div><br></div><div>However, this does not sound right. </div><div>What would be the right way to pass this information from clang to LLVM?</div><div>Will using metadata for this purpose be a right solution? </div>
<div>
(insn-level metadata for vptr store and module-level metadata for DTORs)</div></blockquote><br></div></div></div><div>Using instruction level metadata for this would be appropriate.  However, I also don't understand why a race on this is truly benign.  I'm also concerned that you're adding even more knobs to clang and IR for special case situations.</div>
</div></blockquote><div><br></div><div>As for "more knobs", Chandler mentioned to me recently that being able to identify vptr accesses will help </div><div>virtual function call inlining, so we may still need this knob for other purposes. </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 style="word-wrap:break-word"><div>  How many more special cases like this are you going to require?</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div><br></font></span></div>
</blockquote></div><br>