[LLVMdev] alias set collapse and LICM

[Daniel Berlin]

You can't win here (believe me, i've tried, and better people than me have
tried, for years :P).
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.

Your basic problem is that all of the alias analyses do not come up with
the same partitioning of the heap.

Worse, some are not even transitive, or even symmetric.

This means one single variable may be in multiple disjoint alias sets in
reality.

(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.)

Let's say you modify AliasSetTracker to not collapse, and handle multiple
disjoint partitions at once.

(Here is here i will draw the equivalence between this and what we've done
before in GCC :) )

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.

(IE you have 1 instruction, and it may MOD 5 different alias sets, each of
which represents a different partitioning of the heap).

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

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.

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).


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.


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)

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).

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.

But if it's outside the loop, you may not care to try to move it further.

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)).

O(N) is the worst case, you can do some pretty good caching to get better.
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.

It's possible to get the same time bounds for store sinking as load sinking
by building MemorySSI instead of MemorySSA :)




On Mon, Apr 27, 2015 at 3:50 PM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> > Can you explain why the alias sets are collapsed into one here?
>
> If I'm reading the code correctly, it is because the readonly call
> aliases all of %a, %b and %c.  Since two pointers can be in two
> different alias sets only if they do not alias, %a has to be in the
> same alias set as the read only call and so does %b and %c.
> Therefore, all of them have to be in the same alias set.
>
> >  Can that collapsing simply be avoided for read-only calls without
> creating a second alias set?
>
> I have not yet come up with a simple scheme to solve that problem
> within AliasSetTracker.  Obviously, that does not mean that there
> isn't one.
>
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150427/f5590111/attachment.html>