Alignment issues with Clang on AMD64 (aka x64/x86-64 etc.)

[AnyOldName3]

Clang/LLVM is much better at SLP autovectorisation than MSVC and GCC, so when compiling for an architecture that has vector instructions, they'll appear a lot in straight-line code even if it's not got any loops and isn't doing any maths. AMD64 guarantees that SSE2 instructions are available, so they get emitted. As an example, the vsg::Options default constructor uses an SSE2 128-bit move (specifically MOVAPS) to zero-initialise two consecutive pointers in one of its std::map members. This instruction requires its target address to be aligned to a 16 byte boundary, and because alignof(vsg::Options) is 16, that's guaranteed by the language...

Except the VSG allocator still uses eight byte alignment by default, so when it's used to allocate storage for vsg::Options, it can be misaligned, and its constructor explodes because an instruction operates on an illegal address.

Either the default alignment needs increasing to sixteen (and we need to hope that the VSG allocator is never used for a type with a wider alignment and that Clang never notices that and attempts to use a wider vector instruction that requires stronger alignment), or the allocator needs to start respecting alignof(WhateverTypeItIsAllocatingStorageFor).

This problem is widespread enough that none of the VSG examples that construct any VSG types launch when compiled with a recent version of Clang on my machine. This is likely related to the Arm MacOS crashes that prompted the alignment being increased from four to eight as Macs use (Apple's fork of an old version of) Clang, although there are some minor details around why eight was enough that I've not dug into - ARM NEON SIMD instructions support eight-byte alignment, but go faster when given a flag to expect sixteen-byte alignment, which I'd expect Clang to use if it thought it could rely on that like it does on AMD64. Possibly it's just one of the quirks of Apple's implementation that it doesn't abort if the alignment hint is incorrect.

[robertosfield]

It strongly looks like vsg::Allocator needs to include the alignment requirements,

The change from alignment 4 to 8 was done to keep the various platforms working the same as far as possible, the downside is CPU performance on Intel/AMD dropped as alignment of 8 packs memory less tightly and this was enough to make a noticeable difference in performance on Linux/Windows with my test larger models.

Changing to 16 might be a case of improving very specific bits of code while reducing cache coherency so I'd expect bench-marking with real-world databases to be critical and wouldn't something we'd want to enable by default - the performance regression I see with changing the default alignment from 4 to 8 is something I'm still not happy about, but tolerate it simple to give a more unified packing across platforms with the hope that this might provide more consistent behavior across platforms.

[AnyOldName3]

I suspect that alignment requirements are part of why the co-allocation strategy used by the VSG isn't common even though other cache-optimisation strategies like std::flat_map are well known and wanted widely enough to make it into the standard library.