On Wednesday, 1 March 2017 at 06:04:32 UTC, Cecil Ward wrote:
struct vec_struct {
alias field this;
bool b;
int8 field;
}
In this code when you look at the generated x64 code output by
GDC it seems to be doing a nice job, because it has got the
offset right for the 256-bit YMM 'field' correct.
Does D automatically propagate the alignment restrictions on
the field to the allocation of static structs or structs on the
stack?
In this case:
struct vec_struct {
bool b2;
struct {
alias field this;
bool b;
int8 field;
}
}
it appears that the offset to 'field' is no longer aligned
correctly - offset is 40 bytes in GDC. I don't suppose the
compiler will use solely unaligned instructions? In any event,
I could take the address of field and then pass that to someone
expecting to pick up something with guaranteed correct
alignment, if I have understood the D docs.
Yeah, it looks like the semantic analysis pass is defeating us
here. It's adding the anonymous struct offset to the aligned
field, ignoring completely the original alignment.
Or... the anonymous struct alignment != largest field alignment,
which probably is the more likely scenario.
Please raise a bug against DMD.
Simple test case would be:
struct vec_struct {
bool b2;
struct {
bool b;
int8 field;
}
}
static assert(vec_struct.b.offsetof == 32);
static assert(vec_struct.field.offsetof == 64);
Noob q: I notice that the GDC opcodes look a bit odd, for
example the compiler generates a 256-bit unaligned fetch
followed by an aligned binary operation (I think), eg a movdqu
followed by a vpaddd r, ymm ptr blah - is the latter
aligned-only? Apologies if I have got this wrong, need to read
up. Would someone sanity-check me?
The x86 allows unaligned loads. But if this is referencing the
above data structure, you shouldn't be seeing this if the fields
were correctly aligned.
