On 2/20/21 2:13 AM, tsbockman wrote:
On Saturday, 20 February 2021 at 05:44:33 UTC, kinke wrote:
There's
https://github.com/dlang/druntime/blob/728f1d9c3b7a37eba4d59ee2637fb924053cba6d/src/core/internal/traits.d#L261.
Thanks! That's helpful.
But AFAIK, the GC only guarantees an alignment of 16 and doesn't
respect any overaligned members or alignment spec for the class.
Well, that's just another reason not to use the GC for my current
project, then: I'm using 256-bit AVX vectors extensively.
That alignment limit really *needs* to be raised to at least 32 bytes,
given that even DMD has some support for AVX. 64 bytes would be better,
since AVX512 is going mainstream soon. And, 128 bytes is the largest
common cache line size, I think?
The GC should align anything over 16 bytes to 32 bytes (at least).
Last I checked*, the GC uses pools of 16-byte, 32-byte, 64-byte, etc
blocks. And you don't have mixed allocations in those pools, e.g. a
block is ALL 16-byte blocks, or ALL 32-byte blocks.
If you specify an alignment of a field in your class, I would expect the
compiler to obey the layout. Which means, your class should be over
32-bytes in size since it has to pad it up to the end. This would align
it to 32-bytes (or more) naturally.
What is the offset of your aligned member in the class? i.e. pragma(msg,
Class.member.offsetof)
1. if classInstanceSize is >= 32, I presume it will always be 32-byte
aligned on the GC (not sure about stack alignment for scope instances)
2. If the offsetof of your member is not a multiple of 32, then you
might have problems.
-Steve
*Note, this was a long time ago I had anything to do with the GC, so
things may have changed.
