[llvm-dev] llvm MemorySSA def-use chains

[Hayrapetyan, Anahit via llvm-dev]

Hi,


I have a question about how llvm MemorySSA works, as seems I misunderstand something.

Consider following code snippet and corresponding IR with MemorySSA annotations (got with opt -print-memoryssa)


void foo(int* b) {

   int a = 0;

   int d = 12;

   if (b) {

       a = 42;

       d = 32;

   }

   int c = a;

   int e = d;

}


; Function Attrs: noinline nounwind optnone uwtable

define void @foo(i32* %b) #0 {

entry:

 %b.addr = alloca i32*, align 8

 %a = alloca i32, align 4

 %d = alloca i32, align 4

 %c = alloca i32, align 4

 %e = alloca i32, align 4

; 1 = MemoryDef(liveOnEntry)

 store i32* %b, i32** %b.addr, align 8

; 2 = MemoryDef(1)

 store i32 0, i32* %a, align 4

; 3 = MemoryDef(2)

 store i32 12, i32* %d, align 4

; MemoryUse(1)

 %0 = load i32*, i32** %b.addr, align 8

 %tobool = icmp ne i32* %0, null

 br i1 %tobool, label %if.then, label %if.end


if.then:                                          ; preds = %entry

; 4 = MemoryDef(3)

 store i32 42, i32* %a, align 4

; 5 = MemoryDef(4)

 store i32 32, i32* %d, align 4

 br label %if.end


if.end:                                           ; preds = %if.then, %entry

; 9 = MemoryPhi({entry,3},{if.then,5})

; MemoryUse(9)

 %1 = load i32, i32* %a, align 4

; 6 = MemoryDef(9)

 store i32 %1, i32* %c, align 4

; MemoryUse(9)

 %2 = load i32, i32* %d, align 4

; 7 = MemoryDef(6)

 store i32 %2, i32* %e, align 4

 ret void

}


Tracking back def-use chain for `%1 = load i32, i32* %a, align 4` first I get `9 = MemoryPhi({entry,3},{if.then,5})` and then as definitions MemoryDef(2) which corresponds to `store i32 12, i32* %d, align 4` and MemoryDef(4) corresponding to `store i32 32, i32* %d, align 4`.  However neither of these stores define `a`, they both define `d`. What I was expecting to get was MemoryDef(3) and MemoryDef(1), which are real definitions for `a`.

Could you please explain what's the reason MemorySSA gives incorrect definitions, and is there any way to get the correct ones.

Thanks.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180809/6885e169/attachment.html>