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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150404/38aaac34/attachment.html>
Eric Christopher
2015-Apr-05 03:55 UTC
[LLVMdev] alloca not in first bb behaving differently
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>
David Chisnall
2015-Apr-05 09:44 UTC
[LLVMdev] alloca not in first bb behaving differently
It's not great IR, but it doesn't look like it should actually crash, just (without SROA) produce comparatively bad code. The alloca is only referenced in the basic block that it exists. If this isn't expected to work, then we should probably improve the documentation of alloca in the language reference. David> On 5 Apr 2015, at 04:55, Eric Christopher <echristo at gmail.com> wrote: > > 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> This segfaults for me. The IR passes the function verifier. Can someone spot > an error? I don't see any.Does it segfault the optimizer or when run? If I run your fragment through opt -O3 (on LLVM trunk) after correcting for syntax (due to the unified pointer type changes), I get define i32 @M() #0 { entry: ret i32 3 } attributes #0 = { nounwind readnone } which looks like what you'd want. Just running it through llc (no -O3) gives me .section __TEXT,__text,regular,pure_instructions .macosx_version_min 14, 1 .globl _M .align 4, 0x90 _M: ## @M .cfi_startproc ## BB#0: ## %if.then movl $333, -4(%rsp) ## imm = 0x14D movl $3, -8(%rsp) movl $3, %eax retq .cfi_endproc .subsections_via_symbols which also looks correct. -- Sanjoy