[LLVMdev] Alloca Requirements

David Greene dag at cray.com
Mon Oct 12 13:07:15 PDT 2009


Are there any implicit assumptions about where alloca instructions
can appear.  I've got a failing test where the only difference 
between a passing test and a failing test is one application of
this code in instcombine:

// Convert: malloc Ty, C - where C is a constant != 1 into: malloc [C x Ty], 1

Seems pretty harmless to me.

Later on the instcombine code does this:

// Scan to the end of the allocation instructions, to skip over a block of
// allocas if possible...

That comment makes me a bit suspicious regarding assumptions about alloca 
placement.

The interesting thing about this testcase is that the extra instcombine makes 
the test pass.  If I omit it, the test fails.  The only differences in the
asm are stack offsets, which leads me to believe that in the failing test 
codegen is not accounting for all allocas properly.

Before this critical instcombine the input code looks like this:

        ; Fails
	%"t$1" = alloca %DV1, align 8		; <%DV1*> [#uses=3]
	%"t$2" = alloca [1 x [1 x <2 x float>]]*, i32 12, align 8		; <[1 x [1 x <2 x 
float>]]**> [#uses=2]
	%tmpcast5 = bitcast [1 x [1 x <2 x float>]]** %"t$2" to %DV2*		; <%DV2*> 
[#uses=2]
	%"t$34" = alloca [9 x [1 x <2 x float>]*], align 8		; <[9 x [1 x <2 x 
float>]*]*> [#uses=3]

Afterward it looks like this:

        ; Passes
	%"t$1" = alloca %DV1, align 8		; <%DV1*> [#uses=3]
	%"t$26" = alloca [12 x [1 x [1 x <2 x float>]]*], align 8		; <[12 x [1 x [1 x 
<2 x float>]]*]*> [#uses=1]
	%"t$26.sub" = getelementptr [12 x [1 x [1 x <2 x float>]]*]* %"t$26", i32 0, 
i32 0		; <[1 x [1 x <2 x float>]]**> [#uses=2]
	%tmpcast5 = bitcast [1 x [1 x <2 x float>]]** %"t$26.sub" to %DV2*		; <%DV2*> 
[#uses=2]
	%"t$34" = alloca [9 x [1 x <2 x float>]*], align 8		; <[9 x [1 x <2 x 
float>]*]*> [#uses=3]

Any thoughts on why this might be a problem?

                                   -Dave



More information about the llvm-dev mailing list