[llvm-dev] [MemSSA] Getting more precise information regarding MemoryPhi

[Hao Jin via llvm-dev]

Hello all,



I am trying to use MemorySSA in my analysis and recently I got a problem
about querying the clobbering memory access.



For the example below, both the loads for %c and %d have the clobbering
memory access 5 = MemoryPhi({if.then,2},{if.else,4}).



I believe it can be further optimized. The stores that actually define %c
are; 1 = MemoryDef(liveOnEntry) and ; 3 = MemoryDef(liveOnEntry) so the
clobbering memory access for the load of %c could be another
MemoryPhi({if.then,1},{if.else,3}).



I understand that it is the design of memorySSA to have a single MemoryPhi
for each Basicblock but I am wondering if I want to have more precise
information like this, should this be done as a part of MemSSA/Walker or
should the analysis that uses MemorySSA handle this?



Thank you for your time and I am looking forward to your reply.

Best,

Hao



int foo(int a, int b, int m){

  int c;

  int d;

  if(m){

    c = a;

    d = b;

  }else{

    c = a;

    d = b;

  }

  return c+d;

}



Corresponding IR and MemSSA dump:

define dso_local i32 @foo(i32 %a, i32 %b, i32 %m) {

entry:

  %c = alloca i32, align 4

  %d = alloca i32, align 4

  %tobool = icmp ne i32 %m, 0

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



if.then:                                          ; preds = %entry

; 1 = MemoryDef(liveOnEntry)

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

; 2 = MemoryDef(1)

  store i32 %b, i32* %d, align 4

  br label %if.end



if.else:                                          ; preds = %entry

; 3 = MemoryDef(liveOnEntry)

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

; 4 = MemoryDef(3)

  store i32 %b, i32* %d, align 4

  br label %if.end



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

; 5 = MemoryPhi({if.then,2},{if.else,4})

; MemoryUse(5) MayAlias

  %0 = load i32, i32* %c, align 4

; MemoryUse(5) MayAlias

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

  %add = add nsw i32 %0, %1

  ret i32 %add

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210309/e8acae55/attachment.html>