Memory SSA for this problem?

I am trying to figure what is the best way to do the following in LLVM. Specifically wonder if MemorySSA can be used here…any pointers to existing code that does something similar will be useful.

Consider this code:

%foo = load i256, i256* @G

possible uses of %foo

%bar = call i32 @Bar(i256 %foo)

Now if I know that there are no writes to @G between the load and the call, I would like to convert the call to @Bar to a call to @BarP which accepts a pointer to i256:

%bar = call i32 @BarP(i256* @G)

How can I check if there are no clobbers of @G between the load and the call? @G does not alias with any other memory but there can be writes to @G between the above load and the call and if so, the safe thing to do is:

%foop = alloca i256
store i256 %foo, i256* %foop

%bar = call i32 @BarP(i256* %foop)

Note that I am trying to avoid creating a copy of %foo on the stack when possible.

The goal here is to keep the wide integer in SSA form (there is performance benefit in doing this) but when I have to pass the wide vector to a library function, I want to pass its address. Since @G may be a copy of %foo, I would like to pass @G instead of creating a temp with alloca whenever it is safe to do so. The question is how to check if @G still has the same value as %foo.


Hi Riyaz,

With MemorySSA you could query clobbering on the G at the Bar callsite using the API: MemoryAccess *getClobberingMemoryAccess(MemoryAccess *MA, const MemoryLocation &Loc), where MA is “the MemoryAccess associated with Bar”->getDefiningAccess() and Loc is the memorylocation defining G.
If the returned clobber access dominates the load, then there are no additional clobbering accesses between the load and the call.


Thanks Alina. This is exactly what I wanted to do. But what would “MemoryAccess associated with Bar” be? Notice that in the original code Bar (before I rewrite Bar to BarP), Bar didn’t read any memory. It was passed %foo (target of load) by value. Do I have to create an artificial memory access instruction before calling MemorySSA? Am I missing something here?

Does Bar have attribute ‘read/write none’? Test MSSA->getMemoryAccess(BarInstruction); and see if there’s a MemoryAccess associated with the instruction.
You should not create an artificial MemoryAccess.