Actually, I am implementing a new backend. The hardware support vector of 512 bits. But vector type should be aligned to 1024 bits in memory. So I added "v512:1024" to datalayout for both clang and llvm.
Unfortunately Clang will crash for some cases. The reason is that, when calculating the size of an array of vector, llvm will consider the alignment of the element of an array, but clang will not. When calculating the size of type [10 x <16 x i32>], llvm considers each element's store size which aligns each element's size to its alignment.
After adding "v512:1024" to datalayout, llvm considers the size of [10 x <16 x i32>] to be 10240 bits.
But Clang still considers its size to be 5120 bits. So when this array is in a struct, Clang crashes in CGRecordLowering::clipTailPadding().
the "getSize(Prior->Data)" function will consider the alignment of element. When "Prior" points to the first field "arr" of struct container, "Tail" is 1024x10/8 = 1280 bytes. That's the size of type [10 x <16 x i32>] considering alignment.
At the first iteration of for loop, "Member" points to the second field "val" of struct container. "Member->Offset" is 640bytes.
"if (Member->Offset < Tail)" is true, and the execution goes in. And later "else" branch is executed.
The "assert" in else clause will fail, and clang will crash.
I think when caculating the size of an array, the alignment of element should also be considered. But it is not the case in code.
I am not sure whether it is a bug in clang or there is something I don't know.