[LLVMdev] alloca not in first bb behaving differently

[Eric Christopher]

Allocas not in the entry block are treated as dynamic allocas and not stack
slots.

On Sat, Apr 4, 2015, 8:37 PM Dave Pitsbawn <dpitsbawn at gmail.com> wrote:

> Here is some IR that is working and executing as expected -- All allocas
> are in the first basic block, and only updates happen in other basic blocks.
>
> define i32 @f() {
> entry:
>   %x = alloca i32
>   store i32 333, i32* %x
>   %i = alloca i32
>   store i32 11, i32* %i
>   br i1 true, label %if.then, label %if.else
>
> if.then:                                          ; preds = %entry
>   store i32 3, i32* %i
>   %0 = load i32* %i
>   ret i32 %0
>
> if.else:                                          ; preds = %entry
>   ret i32 2
>
> if.end:                                           ; preds = %after_ret1,
> %after_
> ret
>   ret i32 1
>
> after_ret:                                        ; No predecessors!
>   br label %if.end
>
> after_ret1:                                       ; No predecessors!
>   br label %if.end
>
> after_ret2:                                       ; No predecessors!
>   ret i32 0
> }
>
> The following IR is slightly different in that the alloca is defined not
> in the first basic block:
>
> define i32 @M() {
> entry:
>   %x = alloca i32
>   store i32 333, i32* %x
>   br i1 true, label %if.then, label %if.else
>
> if.then:                                          ; preds = %entry
>   %i = alloca i32
>   store i32 3, i32* %i
>   %0 = load i32* %i
>   ret i32 %0
>
> if.else:                                          ; preds = %entry
>   ret i32 2
>
> if.end:                                           ; preds = %after_ret1,
> %after_
> ret
>   ret i32 1
>
> after_ret:                                        ; No predecessors!
>   br label %if.end
>
> after_ret1:                                       ; No predecessors!
>   br label %if.end
>
> after_ret2:                                       ; No predecessors!
>   ret i32 0
> }
>
> This segfaults for me. The IR passes the function verifier. Can someone
> spot an error? I don't see any.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150405/7311ec87/attachment.html>