<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 14, 2016 at 2:20 PM, Sebastian Pop <span dir="ltr"><<a href="mailto:sebpop.llvm@gmail.com" target="_blank">sebpop.llvm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Sep 13, 2016 at 7:38 PM, Daniel Berlin via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Actually, you can build a walker already that will give you war dependence<br>
> info.<br>
<br>
</span>The more I try, the more I think WAR dependences cannot be extracted<br>
from the current MemorySSA walker: all liveOnEntry uses would not<br>
be reached by walking through the MSSA.<br></blockquote><div><br></div><div>It must be linked to some store, so this is false.<br></div><div>In fact, it must be linked to either live on entry (which has uses), or a store that clobbers your store in use-optimized memoryssa.</div><div>In non-use-optimized memoryssa, you would also have to walk downward uses because it may be attached to something else.</div><div><br></div><div><span><br>
</span>>The users of CurrentStore are all downwards: these users are RAW<br>>dependent on CurrentStore.</div><div><br></div><div>Yes.</div><div><br></div><div>
<span><br>
> if (isa<MemoryUse>(User))<br>
> UseWorklist.push_back(User)<br>
><br>
> while (!UseWorklist.empty())<br>
> CurrentAccess = UseWorklist.pop_front();<br>
> if (StoreClobbersLoad(OriginalSto<wbr>re, CurrentAccess)) // This is<br>
> instructionClobbersQuery, basically<br>
> return CurrentAccess // If you change this to insert it into a set<br>
> instead of returning, you can get the entire set of dominating aliased loads<br>
><br>
> // Keep going up until we've gotten past the attempted hoist point<br>
> if (!MSSA->dominates(CurrentStore<wbr>, HoistPoint))<br>
> OuterWorklist.push_back(cachin<wbr>gWalker->getClobberingAccess(C<wbr>urrentStore->getDefiningAccess<wbr>()))<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The only way to reach uses above a store is by walking through the<br>
def-def chain as in the above line, and then from there walking all the<br>
uses, that may also be uses of OriginalStore.</blockquote></div><div><br></div><div>No.</div><div><br></div><div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This is exactly what is currently implemented in trunk: from OriginalStore<br>
we go to ->getDefiningAccess() and from there we walk through all uses.<br>
It does not work because when the def-def chain may point to a store that<br>
does not clobber the OriginalStore, </blockquote><div><br></div><div>getDefiningAccess does not, but getClobberingMemoryAccess gives you something that *does* clobber it.</div><div><br></div><div>This is why i said:<br>Given how we determine aliasing, and we use optimize, an aliased load must be attached to *either* live on entry, *or* a store that clobbers your store</div><div><br></div><div>This is guaranteed by the property of use optimization.</div><div>Now, if use-opt failed, then yeah, you may have to go through everything. </div><div><br></div><div>Note: I don't claim this is efficient or sensible. I'm simply refuting the claim that they literally cannot be extracted.</div><div><br></div><div>They can.</div><div>It's just inefficient as hell :)</div><div><br></div><div><br></div><div>Note that dependence does not necessarily help you with safety in some of the trickier cases of what you can tag loads with (invariantness, etc). You may not be able to hoist stores anyway, even though they have no noticeable WAR dependence.</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and then the reachable uses are not<br>
clobering OriginalStore.</blockquote><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Another example in which there is no def-def chain and<br>
it is illegal to move the store above the load:<br>
load @A ; MemoryUse(LiveIn)<br><span>store @A ; 1 = MemoryDef(LiveIn)</span></blockquote>
<span>
<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">liveOnEntry uses cannot be reached by walking through the MSSA.</blockquote>
</div><div><br></div><div>Uh?<br><br></div><div>These will both be uses of the live on entry access.</div><div>It's a real access, it has real uses :)</div><div><br></div><div><br></div></div><br></div></div>