Why a One‑Byte Write Can Trigger a Thousand Extra Memory Accesses in C++

During a regression test a tiny change—adding a uint8_t status flag write inside a hot loop of an int8 quantization kernel—made the program run about 30% slower. All functional tests passed and the profiler showed no new cache misses, branch mispredictions, or false sharing.

Running objdump on the compiled binary revealed the culprit: inside the loop an extra instruction vmovss (%rcx), %xmm1 loads the scale factor on every iteration. The factor should have been loaded once before the loop, so a thousand‑element loop performed a thousand unnecessary memory accesses.

Root cause: character‑type aliasing exemption

The added uint8_t write triggers the C++ rule that grants an "alias‑anything" exemption to character types. When the compiler sees a write through a char*, unsigned char* or std::byte*, it must assume that any object in the same storage might be modified, including the scale variable located elsewhere. Consequently the compiler can no longer hoist the scale load out of the loop.

The strict aliasing rule lives in [basic.lval] of the C++ standard (N4950, §11). It states that if a glvalue accesses an object whose type is not similar to the object's dynamic type, the behavior is undefined. The list of "similar" types consists of:

the object's dynamic type

the signed or unsigned version of that type char, unsigned char or std::byte In C++17 (N4659) the list had eight separate clauses; C++20/23 collapsed them into three, but the semantic meaning is unchanged.

Asymmetry of the exemption

The rule applies only to the *access type*, not to the object itself. Writing through a char* tells the optimizer that "any object" might be affected, so it must conservatively assume the worst. The reverse—reading a T* from a char object—is undefined behavior, but compilers treat it symmetrically: they assume both directions may alias, effectively turning the one‑way exemption into a two‑way barrier.

Why the optimizer cares (TBAA)

Type‑Based Alias Analysis (TBAA) gives the compiler the assumption that pointers of different types do not alias. This enables dead‑store elimination, memory‑reordering, auto‑vectorization, and other optimizations. The compiler encodes the aliasing information as a type tree where the root node is the so‑called “omnipotent char”. In LLVM (see clang/lib/CodeGen/CodeGenTBAA.cpp) the function getChar() creates a node named "omnipotent char" and all scalar types are children of this node. Because char is an ancestor of every other scalar type, any access involving char is considered a possible alias.

GCC implements the same idea with alias‑set 0, a universal set that conflicts with every other set.

Minimal reproducible example

void quantize(int32_t* out, const float* in, int n,
               const float* scale, uint8_t* tag) {
    for (int i = 0; i < n; ++i) {
        out[i] = std::lround(in[i] * (*scale)); // *scale is a single load
        tag[i>>5] = 1;                         // the problematic uint8_t write
    }
}

When tag is a uint8_t*, LLVM treats it as an "omnipotent char" pointer, so the store to tag[i>>5] is assumed to possibly modify *scale. The compiler therefore cannot move the *scale load out of the loop, resulting in the extra vmovss per iteration.

Mitigation strategies

Move byte writes out of hot loops (as the author eventually did, restoring the original performance).

Use __restrict or -fno-strict-aliasing to tell the compiler that pointers do not alias, at the cost of losing other TBAA‑based optimizations.

Prefer memcpy (or std::bit_cast in C++20) for type‑punning instead of casting through a char*. Modern compilers can turn a memcpy of a few bytes into a register move with zero runtime cost.

In C++23, use std::start_lifetime_as<T>(ptr) to legally start the lifetime of an object in a byte buffer, eliminating the need for unsafe aliasing.

When portable byte manipulation is required, use unsigned char or std::byte explicitly; uint8_t is not guaranteed to be a character type.

Conclusion

The character‑type aliasing exemption is a powerful language feature that enables generic byte‑wise operations such as memcpy, serialization and hashing. However, every write through a char* or std::byte* forces the optimizer to discard assumptions about unrelated objects, potentially causing massive performance regressions as demonstrated by the extra thousand loads. Understanding the one‑way nature of the rule, how compilers implement it (the omnipotent‑char tree), and employing modern C++ facilities ( std::bit_cast, std::start_lifetime_as) or careful code restructuring can mitigate the hidden cost.

All data and analysis are based on the C++ standard (N4950, N4659) and the source code of LLVM/Clang and GCC.