alloca not in first bb behaving differently

Project Infrastructure LLVM Dev List Archives
#1

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.

#2

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

#3

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

#4

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.

#5

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.

#6

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

#7

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

#8

Maybe the IR doc should be updated to reflect these fine points.