History of the question originates from the pre-C++20 era where developers relied on compiler-specific intrinsics such as __builtin_assume_aligned (GCC/Clang) or __assume_aligned (MSVC) to vectorize loops over memory buffers. C++20 standardized this capability in <memory> to provide a portable mechanism for informing the compiler that a pointer satisfies a stricter alignment contract than the type system guarantees. This addresses the performance gap encountered when processing raw memory from std::malloc, network buffers, or DMA regions that happen to be aligned (e.g., to cache lines or SIMD register widths) but appear to the compiler as merely byte-aligned void* pointers.
The problem centers on compiler conservatism: without explicit knowledge of alignment, the optimizer must generate unaligned load/store instructions (e.g., movups on x86-64) or avoid vectorization entirely to prevent hardware traps. This results in suboptimal code generation, particularly for AVX-512 or NEON operations that require strict alignment for maximum throughput. The compiler cannot statically prove that a pointer derived from external storage is 64-byte aligned, even if the application logic ensures it.
The solution is std::assume_aligned<N>(ptr), a [[nodiscard]] constexpr function that returns ptr unchanged but attaches an alignment assumption to the value in the compiler's intermediate representation. This contract permits the optimizer to emit aligned SIMD instructions (e.g., vmovdqa) and reorder memory operations based on the guarantee that the address modulo N equals zero. If the programmer violates this contract—passing a pointer that is not actually N-byte aligned—the program invokes undefined behavior, which may manifest as SIGBUS on strict RISC architectures (ARM, SPARC) or silent data corruption on x86-64.
#include <memory> #include <immintrin.h> void scale_aligned(float* data) { // Programmer asserts 32-byte alignment (AVX requirement) auto* ptr = std::assume_aligned<32>(data); // Compiler generates vmovaps (aligned load) without runtime checks __m256 vec = _mm256_load_ps(ptr); vec = _mm256_mul_ps(vec, _mm256_set1_ps(2.0f)); _mm256_store_ps(ptr, vec); }
Problem description involved a high-frequency trading (HFT) system processing fixed-width market data records from a kernel-bypass network driver. The driver guaranteed that incoming buffers were page-aligned (4KB), implying 64-byte alignment necessary for AVX-512 parsing. However, the API exposed these buffers as std::byte*. Without alignment information, the compiler generated conservative unaligned move instructions (vmovdqu8), causing the critical path to consume 120 nanoseconds per packet, exceeding the 80ns latency budget.
One solution considered was manual runtime alignment checking using reinterpret_cast<uintptr_t>(ptr) % 64 == 0 followed by dual code paths for aligned and unaligned processing. This approach guaranteed safety but introduced a branch misprediction penalty in the hot loop and doubled the instruction cache footprint. The performance degraded further to 140ns per packet due to frontend stalls, making this solution unacceptable for the latency target.
Another alternative involved using std::align to create a properly aligned sub-buffer within the received memory, skipping the initial bytes. While this eliminated undefined behavior, it wasted up to 63 bytes per packet and complicated the zero-copy architecture, as downstream components expected data at specific offsets within the DMA buffer. The memory fragmentation and pointer arithmetic overhead added 15ns of latency, still missing the budget.
The chosen solution applied std::assume_aligned<64>(ptr) after a debug-only assert verified the driver contract. In release builds, the assertion vanished, leaving only the optimization hint. This allowed the compiler to emit vmovdqa64 instructions and fully unroll the parsing loop across ZMM registers. This approach was selected because the hardware specification provided an immutable guarantee of page alignment, rendering the assumption provably safe by construction.
Result achieved a stable 65ns per packet processing time, well under the 80ns threshold. Profiling confirmed 100% utilization of AVX-512 units and zero unaligned access penalties. The system maintained deterministic latency without sacrificing code clarity or safety in debug builds.
Does std::assume_aligned perform a runtime alignment check or modify the pointer address?
No. std::assume_aligned is purely a compiler directive with zero runtime overhead. Unlike std::align, which calculates and returns a new pointer at an aligned offset within a buffer, std::assume_aligned returns the exact same address it receives. The function merely annotates the pointer value in the compiler's internal representation. If the alignment guarantee is violated at runtime, there is no graceful degradation or exception; the program immediately enters undefined behavior, potentially crashing with SIGBUS on ARM or executing illegal instructions on architectures with strict alignment requirements.
What distinguishes alignas from std::assume_aligned in terms of object lifetime and storage duration?
alignas is a declaration specifier that affects the alignment requirement of a type or variable, influencing how the compiler lays out storage during object creation. It impacts the value returned by alignof and ensures that variables on the stack or in static storage are properly positioned. std::assume_aligned, conversely, makes no changes to memory layout or object lifetime; it is an optimization hint applied to an existing pointer value. You cannot use alignas to retroactively align memory returned by std::malloc, but you can use std::assume_aligned to promise the compiler that the allocation happens to satisfy the constraint, provided you have external knowledge (e.g., using posix_memalign).
Can std::assume_aligned be safely used with pointers from std::vector<T> or standard new T[]?
Generally, this is unsafe unless T has no extended alignment or a custom aligned allocator is employed. Prior to C++23, std::allocator (used by std::vector) did not guarantee over-alignment for types with alignas specifiers larger than alignof(std::max_align_t). While new (since C++17) supports over-alignment via ::operator new(size_t, std::align_val_t), std::vector historically failed to propagate these requirements correctly to the allocator. Therefore, assuming alignment beyond the fundamental alignment for vec.data() invokes undefined behavior unless the vector uses a polymorphic resource (std::pmr) or custom allocator explicitly providing such guarantees.