<br><br><div class="gmail_quote">On Mon, Mar 19, 2012 at 5:24 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.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="im">On Mon, Mar 19, 2012 at 4:52 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
> On Mon, Mar 19, 2012 at 4:46 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Given that, I'm not sure I really see the issue with just<br>
>> special-casing any store where the value stored is a pointer to a<br>
>> global... but it could be argued either way, I guess.<br>
><br>
><br>
> I users expect this to "just work", why not extend the language and make it<br>
> just work?<br>
<br>
</div>I'm not sure anyone really expects this to "just work", just that they<br>
did it by accident.  Making cross-thread unsynchronized virtual calls<br>
on an object which is being destroyed strikes me as a construct nobody<br>
would intentionally write.<br>
<div class="im"><br>
> We could, as an implementation, decide to emit these as relaxed atomic<br>
> stores, making the code well defined without changing the semantics (or<br>
> optimization) in any meaningful way, right?<br>
<br>
</div>Making all vptr loads and stores atomic would block some optimizations<br></blockquote><div><br></div><div>.. and will not solve my problem -- I still need to distinguish between </div><div>"benign-for-practical-purposes" and "definitely-harmful" vptr races. </div>
<div>The only difference between those two cases lies outside of the instrumented function.</div>(it depends on the dynamic type of the object being destroyed). </div><div class="gmail_quote"><br></div><div class="gmail_quote">
--kcc <br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(specifically, we can't perform certain optimizations involving<br>
memcpy, and IIRC some optimizers have incomplete atomics handling).<br>
Not sure if it would have much practical impact, though.<br>
<br>
Specifically just making vptr stores in destructors "unordered", and<br>
making unordered stores which don't change the stored value<br>
effectively no-ops in the memory model, could work too; the potential<br>
impact on optimization is much less, and I don't think the model<br>
changes would lead to any optimizer changes.<br>
<br>
-Eli<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br>