<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 August 2015 at 17:30, Reid Kleckner via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">rnk added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D12277#231179" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12277#231179</a>, @majnemer wrote:<br>
<br>
> Are these intrinsics supposed to be compiler barriers? Seems like bad stuff could happen if we speculated or sunk around them.<br>
<br>
<br>
</span>They have no constraints, which means they are equivalent to a normal external function call. Isn't that enough of a barrier? I think most users (kernels, hypervisors) are fine with LLVM reordering identified object memory accesses across such a barrier.<br></blockquote><div><br></div><div>Surely at least LGDT would be sensitive to reordering of both execution and data accesses, given that you MAY have changed the meaning of code and data segments (although not until they are re-loaded, so that's probably separate intrinsic call, so maybe that's fine?) SGDT is obviously reasonably benign.<br><br>--<br></div><div>Mats <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D12277" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12277</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>