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

]]**> [#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

]*]*> [#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

]*]*> [#uses=3]

Any thoughts on why this might be a problem?

-Dave