Determine if we can ensure `Vector64<T>`, `Vector128<T>`, and `Vector256<T>` are appropriately aligned for RVA statics and the stack.

[tannergooding]

The Vector64<T>, Vector128<T>, and Vector256<T> types are special and are directly mapped as the primitive ABI types (typically referred to as __m64, __m128, and __m256). If possible (i.e. it can be done in a "pay for play" manner), we should look at ensuring these types meet the alignment requirements for stack locals and RVA statics.

category:cq
theme:vector-codegen
skill-level:expert
cost:large
impact:small

[tannergooding]

CC. @jkotas, @fiigii, @CarolEidt

[tannergooding]

As a note: This is not suggesting we fixup the alignment of these types for GC tracked objects, since previous discussions indicated it would likely not be possible to do this in a "pay for play" manner. This is only suggesting we do this for RVA statics and stack locals, since those are never moved and we can likely do it in a "pay for play" manner (it only impacts users which have those types of statics or locals).

[fiigii]

alignment requirements for stack locals

Seems we already have the code for local vars, i.e., int getSIMDTypeAlignment(var_types simdType);.

[jkotas]

we do this for RVA statics

This would be interesting to do for RVA statics only if we do complex pre-initialized RVA statics feature (dotnet/designs#46).

stack locals

If the unmanaged compilers align the stack locals with these, it would make sense to do the same.

[tannergooding]

This would be interesting to do for RVA statics only if we do complex pre-initialized RVA statics feature (dotnet/designs#46).

Agreed. Although I seem to recall something about us already trying to align RVA statics to a 16-byte boundary (or maybe I'm misremembering)?

• If we are, this is beneficial for cases where users are declaring ROSpan<T> for primitive types, and then loading those using LoadVector128; and should also be beneficial for Vector256<T>, except for when it crosses a cache-line boundary
• Looks to be the logic centered around CORJIT_ALLOCMEM_FLG_RODATA_16BYTE_ALIGN

[CarolEidt]

I can't speak to the RVA statics case, but I believe that the JIT aligns 16-byte vectors to 16-byte boundaries. So I think the only missing capability here is alignment on 32-byte boundary for Vector256.
On that note, I see that Compiler::lvaAllocLocalAndSetVirtualOffset() is ensuring that 32-byte vectors have a 32-byte aligned stack offset. But I don't think that code makes any sense because the stack is only aligned on a 16-byte boundary.
@tannergooding - would you concur with these observations?
Also, I'm putting this in Future as I don't see us making any modifications to alignment in the near term.

[tannergooding]

I can't speak to the RVA statics case, but I believe that the JIT aligns 16-byte vectors to 16-byte boundaries.

Yes, this appears to be the case for the following cases:

• Vector128<T>, Vector256<T>, and Vector<T> for locals
• Vector128<T> and Vector256<T> when contained in a struct which is a local

This does not appear to be the case for:

• Vector<T> when contained in a struct which is a local (likely because the packing is not adjusted in the VM, as is done for Vector128<T> and Vector256<T>)

On that note, I see that Compiler::lvaAllocLocalAndSetVirtualOffset() is ensuring that 32-byte vectors have a 32-byte aligned stack offset. But I don't think that code makes any sense because the stack is only aligned on a 16-byte boundary.

Right, it looks like this results in the following. For:

byte u8 = default;
Vector256<byte> v256 = default;

If u8 is 16-byte aligned, v256 will also be 16-byte aligned (32-bytes after u8)
If u8 is 32-byte aligned, v256 will also be 32-byte aligned (32-bytes after u8)

Ideally the actual behavior would be that v256 appears either 16 or 32-bytes after u8; so that it is 32-byte aligned (rather than just offset 32-bytes).

[tannergooding]

This, of course, does not apply to classes which contain any of the above, as the GC only guarantees 8-byte alignment.

[CarolEidt]

Ideally the actual behavior would be that v256 appears either 16 or 32-bytes after u8; so that it is 32-byte aligned (rather than just offset 32-bytes).

This would require either that we align stack frames at 32-bytes, or do dynamic alignment. The former has impact to memory usage, while the latter adds considerable complexity to the JIT. We'd have to do a cost-benefit analysis, and I'm thinking we'd have to figure out a clean JIT approach for the latter to ensure pay-for-play.

[BruceForstall]

Related: #11039