I’m trying to use vectors inside structs with LLVM. I have the following C definition of my struct:
struct Foo
{
uint32_t len;
uint32_t data[32] __attribute__ ((aligned (16)));
};
and here’s some LLVM code to add 42 to element number 3 of the data field:
%Foo = type { i32, <32 x i32> }
define void @process(%Foo*) {
_L1:
%data = getelementptr %Foo* %0, i32 0, i32 1
%vec = load <32 x i32>* %data
%x = extractelement <32 x i32> %vec, i32 3
%xNew = add i32 42, %x
%vecNew = insertelement <32 x i32> %vec, i32 %xNew, i32 3
store <32 x i32> %vecNew, <32 x i32>* %data
ret void
}
However, the output of llc is as if vectors had to be aligned at 128 bytes, which seems wasteful, and also wrong (AFAIK vectors should be 16-byte-aligned):
.file "process.bc"
.text
.globl process
.align 16, 0x90
.type process,@function
process: # @process
.Leh_func_begin0:
# BB#0: # %_L1
movdqa 128(%rdi), %xmm0
pextrd $3, %xmm0, %eax
addl $42, %eax
pinsrd $3, %eax, %xmm0
movdqa %xmm0, 128(%rdi)
ret
.Ltmp0:
.size process, .Ltmp0-process
.Leh_func_end0:
Of course, if I change the C definition to also align the data field at 128 bytes, it works, but wasting 124 bytes (compared to 12 if using 16-byte alignment) just seems wrong. So what’s going on here?
I think your GEPs are a little off for the best codegen. Here’s some C code that does something similar:
which clang turns into this:
and the corresponding nice code you’d expect:
That said, the code you have there is isn’t right and should be:
and is even worse in ToT so a bug report wouldn’t go amiss there.