<div dir="ltr">Sorry, again, i don't think this is a thing memdep should be doing.<div>If GVN can't handle this sanely, that's on GVN.</div><div>So i'm not going t approve this.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 27, 2018 at 11:16 PM, Shiva Chen via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">shiva0217 added a comment.<br>
<span class=""><br>
In <a href="https://reviews.llvm.org/D44891#1048252" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D44891#1048252</a>, @dberlin wrote:<br>
<br>
> This isn't correct in the face of atomics and volatiles, and IMHO, MemoryDependence should not be performing this optimization.<br>
>  If you want, teach GVN to requery MemDep in these cases.<br>
<br>
<br>
</span>Hi @dberlin.<br>
The patch code will not apply when face atomics and volatiles due to MemoryDependence has atomic and volatile checking before entering this part.<br>
It detects the case in the summary, and then MemDep will not clobber "LItoSI" load value by store and then GVN could remove "QueryInst" load by requiring MemDep.<br>
So the patch will not perform optimization by itself, it will let GVN deal with it.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D44891" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D44891</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>