Thanks all. David why do you say it is particularly bad IR (other than not having gone through SROA). Is it the multiple blocks for early returns? That is how I'm supporting early returns in the middle of a basic block. I couldn't find any other way. On Sun, Apr 5, 2015 at 6:24 AM, David Jones <djones at xtreme-eda.com> wrote:> Data point: > > I use (rarely) alloca in basic blocks other than the entry block, and it > works. > > The one point to be aware of: alloca is "cleaned up" only when the > function returns. If you use alloca in a loop, and you have no other > mechanism to deal with it, you will blow out your stack and segfault. > > One way to deal with this is to use llvm.stacksave before the alloca ad > llvm.stackrestore after you're done. These functions can serve to do > "proper" middle-block allocations, creating temporary storage that is valid > only as long as you need it. > > Note to self: good call to do all of your "longer term" allocas in the > entry block. Don't move them to inner blocks even if you think you can, as > SROA won't touch them. > > > > On Sun, Apr 5, 2015 at 5:44 AM, David Chisnall < > David.Chisnall at cl.cam.ac.uk> wrote: > >> 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 >> >> >> _______________________________________________ >> 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150405/f5698810/attachment.html>
David Chisnall
2015-Apr-06 10:02 UTC
[LLVMdev] alloca not in first bb behaving differently
On 5 Apr 2015, at 16:52, Dave Pitsbawn <dpitsbawn at gmail.com> wrote:> > David why do you say it is particularly bad IR (other than not having gone through SROA).If you place all of your allocas (other than ones for things like C VLAs in loops) at the start of the entry basic block and then use the lifetime markers for local variables with restricted scope, you make it much easier for the optimisers to handle the code. For something this simple, it probably doesn't make a difference (I'd expect SROA + SimplifyCFG to optimise the whole thing away), but in more complex code having allocas outside of the first basic block can cause problems. It's generally a good idea to keep around an IRBuilder with an insert point initialised to the start of the entry BB and use this to create allocas. David
Gabriel Dos Reis
2015-Apr-06 12:33 UTC
[LLVMdev] alloca not in first bb behaving differently
On Mon, Apr 6, 2015 at 3:02 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> On 5 Apr 2015, at 16:52, Dave Pitsbawn <dpitsbawn at gmail.com> wrote: > > > > David why do you say it is particularly bad IR (other than not having > gone through SROA). > > If you place all of your allocas (other than ones for things like C VLAs > in loops) at the start of the entry basic block and then use the lifetime > markers for local variables with restricted scope, you make it much easier > for the optimisers to handle the code. For something this simple, it > probably doesn't make a difference (I'd expect SROA + SimplifyCFG to > optimise the whole thing away), but in more complex code having allocas > outside of the first basic block can cause problems. > > It's generally a good idea to keep around an IRBuilder with an insert > point initialised to the start of the entry BB and use this to create > allocas. >Maybe the IR doc should be updated to reflect these fine points. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150406/234edea2/attachment.html>