[PATCH] Update MergedLoadStoreMotion to use MemorySSA

[Daniel Berlin]

> During building, MemorySSA currently optimizes uses to the nearest
> dominating clobbering access for you, done at the suggestion of 2
> people.  We could make it stop doing this (it's just a flag), but the
> tradeoff is most things end up walking more in practice.
> Additionally, as things optimize, and you update memssa, you will
> often end up with the *same result* anyway.  The only way to stop that
> is to make it so you are required to use "nearest dominating
> memorydef" instead of "dominating memorydef" when updating.  We do
> this in the API's where we do insertion (addNewMemoryUse), but we
> don't check/verify it in replaceMemoryAccess style API's, we only
> check standard domination.

The other tradeoff, btw, is that while doing MemoryUse optimization
while building makes this particular algorithm slightly harder, it
makes an (IMHO) much more useful thing a lot easier.

A lot of passes (GVN, memcpyopt, etc) want to know whether they can
replace a load with a load to eliminate something:

1= MemoryDef(liveonentry)
store a
2 = MemoryDef(1)
store b
3 = MemoryDef(2)
store c
4 = MemoryDef(3)
store d
MemoryUse(1)
load a, 4 bytes
load a, 8 bytes
(or different types, or whatever)

By optimizing MemoryUse's during building, we are guaranteed that if
we do getMemoryAccess(load A)->definition(which is store a)->uses, or
we now have all loads that actually use *that* store's value. This
means we can look at the other loads of that store value and see if we
can reuse them.

Doing this without use optimization of uses would be much harder.
you'd need to use a downwards API from the store to get all possible
real uses, which may encompass walking the entire program.

On the other hand, the tradeoff of doing MemoryUse optimization is
that it means to get all the loads in a block, you really have to ask
for all the loads in the block, instead of trying to hope you have
chains that give it to you :)