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

Alina Sbirlea via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 9 12:37:09 PST 2021


Hi,

Adding another MemoryPhi, or altering the current one will make MemorySSA
invalid. So simply creating the instance
`MemoryPhi({if.then,1},{if.else,3})` is not a valid option in the current
implementation, regardless of where it is done.
I would suggest doing the querying you need in the analysis that uses
MemorySSA, and then figure out if it makes sense to have the same mechanics
in a custom walker.

Best,
Alina


On Tue, Mar 9, 2021 at 8:07 AM Hao Jin via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> 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
>
> }
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210309/b10ae059/attachment.html>


More information about the llvm-dev mailing list