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

Hi guys,
a question about updating memory SSA:
Is it expected that e.g insertion of MemoryDef doesn't change all dominated
uses?
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?
Another general question: what is the use of MemorySSAUpdater? When should
I use updater and when the MemorySSA API is sufficient?

Piotr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170217/1027a4b3/attachment.html>

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>

In particular, if you want to add support, the right way to know what to
rename is (off the top of my head)

add a flag or something to have renamepass reset all uses it sees (you only
have to change the uses, defs are all linked together and thus already
fixed by the updater).  Right now it only does that if they have no
defining access.

Make it skip blocks already in the visited set (the incomingval to pass to
successors is the existing incoming val if getDefsList.rbegin()
=getDefsList.rend(), and getDefsList.rbegin() otherwise) to prevent
duplicate work from the below:

Now:
 call renamepass on the bb for the inserted def, using the defining access
of the first def as the incoming val.
call renamepass on the bb of each inserted phi (you can use a null incoming
val since incoming val will  become the phi)

This should rename all of the affected uses.




On Fri, Feb 17, 2017 at 1:37 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
>
>
> 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/6949e9f4/attachment.html>