Consider making size of non-power-of-two primitive types always aligned

[topolarity]

primitive types currently round to the byte for storage:

julia> primitive type Int24 <: Integer 24 end

julia> Base.datatype_alignment(Int24)
4

julia> Core.sizeof(Int24)
3

julia> Base.aligned_sizeof(Int24)
4

The result is that we have three notions of "sizeof" in Julia, analogous to LLVM:

• "storage size": Core.sizeof in Julia, getTypeStoreSize() in LLVM
• "allocation size": Base.aligned_sizeof in Julia, getTypeAllocSize() in LLVM
• "packed bit size": Core.bitsizeof as proposed in core: support odd-bit primitive integers, add Core.bitsizeof #61359, getTypeSizeInBits() in LLVM

There's also a performance trade-off associated with this quirk. If Core.sizeof is not aligned, a Ptr{Int24} must be read / written with a multiple 16- / 8-bit operations, instead of a single 32-bit load / store.

We should consider re-aligning with C23 and making the Core.sizeof aligned (i.e. Core.sizeof(T) == Base.aligned_sizeof(T::DataType)), like it is for every other type in the system. IMO most uses fall squarely into the "packed data" camp (so request the bit size and round up to the byte if you need to) or the "normal allocation" camp (so use Base.aligned_sizeof).

The fact that Core.sizeof is not the allocation size is a somewhat frequent source of confusion, and I've encountered multiple bugs in the wild related to Core.sizeof being used where Base.aligned_sizeof is the right choice.

[Seelengrab]

How will this affect padding, e.g. #49318 ?

[topolarity]

How will this affect padding, e.g. #49318 ?

I think this largely agrees with the discussion in that issue. It won't affect padding within structs or arrays, since the allocated size is not changing. It mostly changes what it means to store / load from these types directly, e.g. whether we can assume the presence of padding bits when we store / load.

edit: This does affect the isbitsegal notion we have in the compiler since it means Int24 is now padded, but I think that's largely superficial. isbits-like comparison is easy to implement for primitive types regardless of padding, and structs already correctly mark these as padded once they appear in a field.

[fingolfin]

Perhaps triage can decide whether to go in this direction or not? It would be good to know so I now how to proceed with PR #61359.

[JeffBezanson]

Triage is ... aligned with this. Good to do whatever C does.