[llvm-dev] [MemorySSA] inserting or removing memory instructions

[Daniel Berlin via llvm-dev]

On Fri, Feb 17, 2017 at 1:19 PM, Piotr Padlewski <piotr.padlewski at gmail.com>
wrote:

> Hi guys,
> a question about updating memory SSA:
> Is it expected that e.g insertion of MemoryDef doesn't change all
> dominated uses?
>
At the moment, it is expected you are essentially just hoisting/sinking
them, not actually changing the aliasing.
The test does not obviously test this constraint, and is pretty contrived.
If you have a use case where we need to rename affected uses, i'm happy to
make it do that, it's trivial.


> For example test case CreateLoadsAndStoreUpdater produces:
>
> define void @F(i8*) {
> ; 1 = MemoryDef(liveOnEntry)
>   store i8 16, i8* %0
> ; 4 = MemoryDef(1)
>   store i8 16, i8* %0
>   br i1 true, label %2, label %3
>
> ; <label>:2:                                      ; preds = %1
> ; 2 = MemoryDef(4)
>   store i8 16, i8* %0
>   br label %4
>
> ; <label>:3:                                      ; preds = %1
>   br label %4
>
> ; <label>:4:                                      ; preds = %3, %2
> ; 3 = MemoryPhi({%3,4},{%2,2})
> ; MemoryUse(3)
>   %5 = load i8, i8* %0
> ; MemoryUse(1)
>   %6 = load i8, i8* %0
> }
>
> What is the general behavior that I can expect when I insert or remove
> def/use?
>

So far, it is built to replace all the hoist/sink/removal/etc cases.
It should work for all of those cases.

For use insertion, it will always be correct.
For stores,  It will even work if you sink a store to a branch.
It will produce wrong results if you insert new stores in the way of old
stores.


Another general question: what is the use of MemorySSAUpdater?
>

To replace hand-written broken updating.

> When should I use updater and when the MemorySSA API is sufficient?
>

Unless you are just removing accesses, you should use the Updater.

Due to the single-variable nature of memoryssa, there are tricky cases that
need to be handled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170217/05178ad6/attachment.html>