To model unaligned loads from memory into vector values, loadUnaligned!V and storeUnaligned!V were added to core.simd, modelled after LDC's eponymous ldc.simd intrinsics: https://github.com/dlang/druntime/pull/1693
Unfortunately, the API was changed over what LDC offers. The store argument order change is benign, although I wish the names had also been changed to `unaligned{Load, Store}` to bring them in line with `{atomic, volatile}{Load, Store}`.
What is problematic, though, is that the signatures have been changed to take a pointer to the vector type instead of a scalar pointer, e.g. int4* instead of int*. This is nonsensical, as the vector type is defined as aligned – e.g. `int4.alignof == 16` –, yet the entire purpose of the function is to load from a possibly unaligned address.
If we follow C rules, the act of merely creating an unaligned pointer is undefined behaviour. The D spec doesn't state what our rules on this are, but it is clear that dereferencing unaligned pointers can't be legal. Thus, users are forced to insert a cast that produces an invalid pointer into their code to be able to use the functions, which can't be a good idea in a strongly typed language.
LDC's primitives require the vector type to be explicitly specified. If that is unwanted, the correct fix is to take a pointer to the corresponding static array type – i.e. int[4]* in the above example – instead, which does not come with the extra alignment properties.
---
Proposal: Deprecate core.simd.{load, store}Unaligned and replace them with new functions unalignedLoad/unalignedStore which take pointers to static arrays. This way, the functionality can be implemented the same way in LDC and DMD without potential for confusion, and in a way that accurately expresses the preconditions on the arguments in the type system.
Comment #1 by robert.schadek — 2024-12-07T13:38:22Z