<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 19, 2012, at 5:13 PM, Kostya Serebryany wrote:</div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><div class="h5"><div><blockquote type="cite"><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></blockquote><br></div><div>Right, but this would have to be designed properly. If someone wants to put forward a concrete use case and a design that would enable virtual call inlining that is also useful for tsan, that would certainly be interesting.</div><div><br></div><div>-Chris</div><br></body></html>