Assert on Large Zeroinitializer Store

Dear All,

I currently have one of my transforms creating the following store instruction:

store [65536 x i8] zeroinitializer, [65536 x i8]* %buf.i, align 16

... which causes the SelectionDAG code to assert out:

Assertion failed: (ResNo < NumValues && "Illegal result number!"), function getValueType, file /Users/criswell/src/llvm/include/llvm/CodeGen/SelectionDAGNodes.h, line 589.

Should LLVM be able to code generate the above store instruction? If not, how large a value can a store instruction store to memory without triggering problems in the code generator?

-- John T.

I don't know the exact limit, but if you're storing an array or struct
with more that 10 elements with a store instruction, you're doing
something wrong. Use memcpy and/or memset instead.

-Eli

Dear All,

I currently have one of my transforms creating the following store
instruction:

store [65536 x i8] zeroinitializer, [65536 x i8]* %buf.i, align 16

... which causes the SelectionDAG code to assert out:

Assertion failed: (ResNo< NumValues&& "Illegal result number!"),
function getValueType, file
/Users/criswell/src/llvm/include/llvm/CodeGen/SelectionDAGNodes.h, line 589.

Should LLVM be able to code generate the above store instruction? If
not, how large a value can a store instruction store to memory without
triggering problems in the code generator?

I don't know the exact limit, but if you're storing an array or struct
with more that 10 elements with a store instruction, you're doing
something wrong.

Okay.

I can certainly use memset (I'm just zero'ing out memory by storing a zeroinitializer). Using stores just looked a little cleaner to me.

Is there a reason why storing a zeroinitializer of such large size is considered "wrong?" It seems like it wouldn't generate any performance hit if the code generator took care of it properly.

-- John T.

In practice, the way we do code generation for constructs involving
first-class structs/arrays assumes that it is reasonable to scalarize
the type in question.

-Eli