Alignment requirements for uint8x16_t being loaded from byte array?

Question

We have an assert firing under Debug builds that checks for alignment. The assert is for a byte array that's loaded into a uint8x16_t using vld1q_u8. While the assert fires, we have not observed a SIG_BUS.

Here's the use in code:

const byte* input = ...;
...

assert(IsAlignedOn(input, GetAlignmentOf(uint8x16_t));
uint64x2_t message = vreinterpretq_u64_u8(vld1q_u8(input));

I also tried with the following, and the assert fires for the alignment of uint8_t*:

assert(IsAlignedOn(input, GetAlignmentOf(uint8_t*));
uint64x2_t message = vreinterpretq_u64_u8(vld1q_u8(input));

What are the alignment requirements for the byte array when loading it into a uint8x16_t with vld1q_u8?

---

In the above code, input is a function paramter. IsAlignedOn checks the alignment of its two arguments, ensuring the first is aligned to at least the second. GetAlignmentOf is an abstraction that retrieves the alignment for a type or variable.

uint8x16_t and uint64x2_t are 128-bit ARM NEON vector datatypes that are expected to be placed in a Q register. vld1q_u8 is a NEON pseudo instruction that is expected to be compiled into VLD1.8 instruction. vreinterpretq_u64_u8 is an NEON pseudo instruction that eases use of the datatypes.

Answer 1

The natural alignment of a VLD1.8 instruction, loading 16 bytes to a Quad register, is a byte. This means that even if unaligned transfers are not permitted, this instruction cannot fault.

So it looks like this specific assertion is not correct.

Answer 2

When writing direct assembler (either inline or in external files) you can choose whether you want to specify the alignment (e.g. vld1.8 {q0}, [r0, :64]) or leave it out (e.g. vld1.8 {q0}, [r0]). If it isn't specified, it doesn't require any specific alignment at all, as Dric512 says.

When using vld1q_u8 via intrinsics, you don't ever actually specify the alignment, so as far as I know, the compiler doesn't assume it, and produces the instruction without alignment specification. I'm not sure if some compilers can deduce some cases where alignment actually is guaranteed and use the alignment specifier in those cases. (Both gcc, clang and MSVC seem to produce vld1.8 without alignment specifiers in this particular case.)

Do note that this is only an issue on 32 bit arm; in AArch64, there's no alignment specifier to the ld1 instruction. But even there, alignment still obviously helps, you'll get worse performance if you use it with unaligned addresses.

Answer 3

Looking at this from the other end, here's an actual definition of that type from the point of view of one example compiler (Visual Studio 2015's arm_neon.h):

typedef union __declspec(intrin_type) _ADVSIMD_ALIGN(8) __n128
{
     unsigned __int64   n128_u64[2];
     unsigned __int32   n128_u32[4];
     unsigned __int16   n128_u16[8];
     unsigned __int8    n128_u8[16];
     __int64            n128_i64[2];
     __int32            n128_i32[4];
     __int16            n128_i16[8];
     __int8             n128_i8[16];
     float              n128_f32[4];

    struct
    {
        __n64  low64;
        __n64  high64;
    } DUMMYNEONSTRUCT;

} __n128;

...

typedef __n128   int8x16_t;

So, on Windows platforms at least, it's going to require no less than the alignment of an __int64 thanks to that union, and from the AAPCS that means 8 bytes (and even without a not-very-challenging guess at what _ADVSIMD_ALIGN(8) could possibly mean...)

---

It's even more straightforward than that, though, because it turns out said AAPCS does actually have the last word in this directly, via its definition of vector types in terms of containerized vectors (§4.1.2):

The content of a containerized vector is opaque to most of the procedure call standard: the only defined aspect of its layout is the mapping between the memory format (the way a fundamental type is stored in memory) and different classes of register at a procedure call interface.

In other words, at the ABI level a vector type is a vector type, regardless of what may or may not be in it, and both 64-bit and 128-bit containerized vectors require 8-byte alignment because the ABI says so (§4.1). Thus regardless of what the underlying instructions might be capable of, the Microsoft implementation isn't even being overly strict as I initially surmised, it's simply conformant. Eight shall be the number thou shalt align, and the number of the aligning shall be eight.

The argument to vld1q_u8(), on the other hand, is a uint8_t const *, whose pointed-to data has no alignment requirement, thus asserting that it meets 8-byte alignment can be expected to fail quite a lot.