<div dir="ltr">You can't win here (believe me, i've tried, and better people than me have tried, for years :P).<div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span style="line-height:1.5;font-size:13.1999998092651px">No matter what you do, the partitioning will never be 100% precise. The only way to solve that in general is to pairwise query over the partitioning.</span><br></div></div><div><span style="line-height:1.5;font-size:13.1999998092651px"><br></span></div><div>Your basic problem is that all of the alias analyses do not come up with the same partitioning of the heap.</div><div><br></div><div>Worse, some are not even transitive, or even symmetric.</div><div><br></div><div>This means one single variable may be in multiple disjoint alias sets in reality. </div><div><br></div><div>(For example, GEP, PHI will give you different AA results than PHI, GEP in some cases. That is mostly a FIXME, but there are plenty of cases you can come up with where info tells you something about one variable and it's relationship to another, but not to a third. The non-symmetric case is rarer, but again, possible.)</div><div><br></div><div>Let's say you modify AliasSetTracker to not collapse, and handle multiple disjoint partitions at once.</div><div><span style="font-size:13.1999998092651px;line-height:1.5"><br></span></div><div><span style="font-size:13.1999998092651px;line-height:1.5">(Here is here i will draw the equivalence between this and what we've done before in GCC :) )</span><br></div><div><br></div><div>The only way to maintain correctness (in general) and not collapse is to maintain multiple alias sets, and say which are affected by which instructions.</div><div><br></div><div>(IE you have 1 instruction, and it may MOD 5 different alias sets, each of which represents a different partitioning of the heap).</div><div><br></div><div>You will discover very quickly, that for most partitioning you can think of, the cost of maintaining the alias sets over a set of instructions with is greater than the cost of additional queries you may come up with in the first place</div><div><br></div><div>In other words, depending on how precise your partitioning you may have variables that clobber 10 or 20 or 30 of the disjoint alias sets. Handling this is a lot more expensive than saying "hey, i want to move this one load up another instruction. Does it really conflict?". This is because you really only care about individual aliases in the alias set at any given time, but unless you go through all the addresses ahead of time, and had a way to say "okay alias set tracker, i only care about variable x, y, z, and even then, only x in block a, y in block b, etc", you are paying the cost of doing whatever queries are necessary to prove something about *all* variables in an alias set.</div><div><br></div><div>MemorySSA was essentially built with this problem in mind (and thus, tries to provide chains that let you do querying on. You ask it about a load, it can O(1) tell you the nearest dominating thing that MOD's it (IE to which getModRefInfo(Instruction, Location) says Mod).</div><div><br></div><div><br></div><div>This means algorithms that use it to hoist, if they are looking to place things in positions that dominate the original load, can be done in O(N) overall.</div><div><br></div><div><br></div><div>It can O(N) tell you the nearest thing (not dominating) that MOD's it, where N is the number of MOD'ing accesses in between the dominating access and the actual MOD'ing access. We could make this O(1) for a space cost (we compute it but throw it away)</div><div><br></div><div>It can O(N) tell you the farthest *down* you can move something (and give you O(N) the nearest post-dominated thing, or the nearest thing).</div><div><br></div><div>It can O(1) tell you the nearest set of uses, and the next "MOD'ing access" (IE the next thing to which getModRefInfo(instruction) says Mod). The nearest common postdominator of all of these is a valid placement point for the store, but may not be the farthest down you can move it.</div><div><br></div><div>But if it's outside the loop, you may not care to try to move it further.</div><div><br></div><div>This means store sinking algorithms are N^2 to sink as far down as you can (though you can get a cheap place, of course, for O(N)).</div><div><br></div><div>O(N) is the worst case, you can do some pretty good caching to get better.</div><div>It's also N=Number of MOD'ing accesses, not N = Number of instructions. They may or may not be the same thing, most of the time they are not.</div><div><br></div><div>It's possible to get the same time bounds for store sinking as load sinking by building MemorySSI instead of MemorySSA :)</div><div><br></div><div><br></div><div><div><br></div></div></div><br><div class="gmail_quote">On Mon, Apr 27, 2015 at 3:50 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Can you explain why the alias sets are collapsed into one here?<br>
<br>
If I'm reading the code correctly, it is because the readonly call<br>
aliases all of %a, %b and %c. Since two pointers can be in two<br>
different alias sets only if they do not alias, %a has to be in the<br>
same alias set as the read only call and so does %b and %c.<br>
Therefore, all of them have to be in the same alias set.<br>
<br>
> Can that collapsing simply be avoided for read-only calls without creating a second alias set?<br>
<br>
I have not yet come up with a simple scheme to solve that problem<br>
within AliasSetTracker. Obviously, that does not mean that there<br>
isn't one.<br>
<br>
-- Sanjoy<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div>