[llvm-commits] patch: fix emission of npot vectors which need trailing padding

[Renato Golin]

On 21 June 2011 06:52, Nick Lewycky <nlewycky at google.com> wrote:
> This lowers to a struct with <3 x float>, which TargetData says is 16 bytes
> on ARM.

Hi Nick,

This only makes sense for ARM with NEON/VFP, unless selection-DAG
identifies it and remove the padding to avoid extra instructions being
generated for the CPU when NEON/VFP is not present.

Anyone knows if that's the case?


> In LLVM IR, the first element becomes a constant aggregate zero,
> which is emitted by looking at how many bytes it is (sixteen) and writing
> out a zero-fill. The second element is emitted as three contiguous elements,
> resulting in a total of 12 bytes.

I agree, we should have consistency here.


> The StructLayout object claims that each of those should be 16 bytes, so I
> changed the AsmPrinter in CodeGen to apply padding to the end of an array to
> match what TargetData thinks the length of the array is. Patch attached,
> please review!

Not sure you changed the right place. I agree that alignment is
important for all platforms but I wouldn't make such an assumption
without a set of tests for each one of them.

If everyone is happy that such padding needs to be dealt with by the
generic CodeGen, I won't oppose, but would be good to have at least
one test for each major architecture.

Otherwise, if you move it to ARMAsmPrinter, I still suggest you to
write a simple IR-to-ASM test and check data sizes.

cheers,
--renato