Hi all,
I was reading the description of run-time stack and alloca instructions in LLVM IR and have a question about the same. Do LLVM alloca instructions allow the processing on stack across some alloca blocks?
For example, is following code valid?
define i32 @f()
{
%0 = alloca i8, i32 16
%1 = ptrtoint i8* %0 to i32
%2 = add i32 %1, 4
%3 = inttoptr i32 %2 to i32*
store i32 5, i32* %3
%4 = alloca i8, i32 20
%kkk = ptrtoint i8* %4 to i32
%5 = add i32 %kkk, 24 -----> Access to previous block
%6 = inttoptr i32 %5 to i32*
%7 = load i32* %6
ret i32 %7
}
Is this kind of accessing across blocks valid? Are we guaranteed that in final executable, this offest processing across blocks would be taken care of properly. I have tried writing some LLVM IRs with these kind of accesses and am getting correct answer( For example, above code is working fine). But wanted to make sure that this is a valid operation in IR.
Thanks
–Kapil
kapil anand wrote:
Hi all,
I was reading the description of run-time stack and alloca instructions in LLVM IR and have a question about the same. Do LLVM alloca instructions allow the processing on stack across some alloca blocks?
For example, is following code valid?
Yes, it's valid. Alloca, like the other non-PHI instructions, only requires that all uses be dominated by the definition.
There's a couple things to know about alloca. One is that you can't free an alloca, so you may want to avoid using them in loops. The other is that the -mem2reg pass will only look for a contiguous list of alloca's at the beginning of the first block which is why nearly all the LLVM IR you'll see puts them together at the top.
Nick
Hi all,
I was reading the description of run-time stack and alloca instructions in LLVM IR and have a question about the same. Do LLVM alloca instructions allow the processing on stack across some alloca blocks?
For example, is following code valid?
No, that code is not valid. Each alloca is considered a distinct object. First example, if the first one was dead (no direct uses), the optimizer will delete it. Accessing %0 from %4's pointer will not work well in general, and is undefined behavior.
-Chris