<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 3, 2015 at 2:50 PM, Diego Novillo <span dir="ltr"><<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@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 dir="ltr">I don't see how this is any different from volatile markers on loads/stores or memory barriers or several other optimizer blocking devices.  They generally end up crippling the optimizers without much added benefit.</div></blockquote><div><br></div><div>Volatile must touch memory (right?). Memory is slow.</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><br></div><div>Would it be possible to stop the code motion you want to block by explicitly exposing data dependencies?  Or simply disabling some optimizations with pragmas?</div><span><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div><div>Code motion would be fine in theory, though as has been proposed, this intrinsic would prevent it (because there isn't an attribute that doesn't allow dead code removal but still permits reordering, as far as I'm aware). Rust doesn't have pragmas, and besides, that would also affect the whole module (or the whole crate, to use Rust's vernacular), whereas this intrinsic would be used in a much more targeted manner (ie at the SSA value level) by the developer and leave the rest of the module unmolested.</div></div></div></div>