<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>It doesn't really make sense to me. The most likely way for the optimizer to break any of this is in the middle end. By only fixing it afterward, I don't see what the advantage of fixing it at all is...</div>
</div></div></div></blockquote><div><br></div><div>Actually I think you're right: we also transform atomics to stable intrinsics, which we then transform back to LLVM IR on the user-side. Using these intrinsics pre-opt would be detrimental to overall performance, but doing volatile->atomic pre-opt and doing atomic->intrinsic post-opt should be OK.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>As Jeffrey pointed out, the penalty is relatively low on x86. </div>
</div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Yes, we discussed performance of our approach extensively for x86-32, x86-64, ARM, MIPS and other potential targets. Our current approach isn't the best one for performance but it's definitely conservative, potentially more portable in the face of bugs, while still being fast-ish and allowing us to loosen up in future releases. It seems like a nice tradeoff for a first launch.</div>
</div>