<div dir="ltr"><br><div class="gmail_extra">Nope, you are right, part of this is giving up in some cases for removing a factor of O(uses) from most checks. But there is more to extract from what it is telling you that *isn't* doing that.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Remember that what it's really telling you is that "any def in between the use and the def it's linked to is no-alias of the use".</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, given, for example:</div><div class="gmail_extra"><br><span style="font-size:12.8px">define i32 @test(i32* %P, i32 %y) {</span><br style="font-size:12.8px"><span class="gmail-m_-8835095014217447538gmail-im" style="font-size:12.8px">; 1 = MemoryDef(liveOnEntry)<br>  store i32 1, i32* %P<br></span><span style="font-size:12.8px">  %Py = getelementptr i32, i32* %P, i32 %y</span><br style="font-size:12.8px"><span style="font-size:12.8px">; 2 = MemoryDef(1)</span><br style="font-size:12.8px"><span style="font-size:12.8px">  store i32 2, i32* %Py</span></div><div class="gmail_extra"><span style="font-size:12.8px">; 3 = MemoryDef(2)</span><br style="font-size:12.8px"><span style="font-size:12.8px">  store i32 1, i32* %P</span></div><div class="gmail_extra"><span style="font-size:12.8px">  %P1 = getelementptr i32, i32* %P, i32 1</span><br style="font-size:12.8px"><span style="font-size:12.8px">; MemoryUse(2)</span><br style="font-size:12.8px"><span style="font-size:12.8px">  %l = load i32, i32* %P1</span><br style="font-size:12.8px"><span style="font-size:12.8px">  ret i32 %l</span><br style="font-size:12.8px"><span style="font-size:12.8px">}</span><br></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px">This proves that MemoryUse(2) cannot affect the store at 1.  If it could, it would have been MemoryUse(3) instead.</span></div><div class="gmail_extra"><span style="font-size:12.8px">MemorySSA already figured this out for you, and currently, you will rediscover it.  In fact, it's better than that, because in just about all cases outside of the pair metadata i referred to earlier, seeing this proves it "for all time" (IE you don't have to ever forget this information)</span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-size:12.8px">IE your statement "</span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">If SI->Current is NoAlias we can't safely treat SI->Use as noalias though."</span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px">This is true in general, but false if a store with the same loc is in between Si->Use and SI->getDefiningAccess()</span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px">You can use OrderedInstructions or something to see if that's the case.</span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-size:12.8px">So basically all i'm asking is that you use the information it's providing you if you can :)</span></div><div class="gmail_extra"><span style="font-size:12.8px">The information it's providing is that "given a use, the use may/must alias with it's def. Anything in between the use and it's current def must be noalias".</span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div>