Compiler Explorer

Source code

/**
* This code snippet demonstrates the effect of "undeterminate state" padding on compiler optimizations.
* I tested this with Clang 19.1.0, GCC 14.2, and MSVC 19.40.
* GCC and Clang were called with the `-O2 -std=c23` flags.
* MSVC was called with the `-std:clatest` flag.
* Both x86-64 and arm-v8 were tested.
*/

#include <string.h> // needed for memset
#include <stdint.h> // needed for known-width integer types

/*
 `S` is a struct that holds 56 bits of data: both Clang and GCC add 8 bits of padding so 
 that `S` is aligned to the 64-bit word size.
*/
struct S
{
    uint32_t x;
    uint8_t y;
    /* uint8_t p; */    // all compilers put here the padding on all architectures
    uint16_t z;
};

/* 
 Since the padding is not touched, all compilers refuse to optimize foo1 by reducing the three 
 assignments into a single 64-bit move.
*/
void foo1(struct S* s)
{
    s->x = 1;
    s->y = 2;
    s->z = 3;
}

/* 
 Here we basically force the optimization by performing a series of casts. 
 This code is flimsy at best: 
    - In general, `S` is not guaranteed to be padded to 64-bits or to be padded at all
    - Even if that is the case, the padding is not guaranteed to be where we think it is.
    - Even if that is the case, little-endianness of the representation is not guaranteed.
    - Even if that is the case, as soon as the fields of `S` are reodered, everything will break.

Interestingly, GCC on ARM still splits this code into multiple assignments.
*/
void foo2(struct S* s)
{
    *(uint64_t*)s = 0x0003'00'02'00000001;
}

/* 
 In C23, empty-initialized structs have all their fields empty-initialized 
 (for unsigned integers, it means zero-initialized), and all padding bits are set to zero.
 GCC optimizes this on x86, but not on ARM. 
 Clang and MSVC both refuse to optimize.
*/
void foo3(struct S* s)
{
    *s = (struct S){};
    s->x = 1;
    s->y = 2;
    s->z = 3;
}

/* 
 the call to `memset` sets the first `sizeof *s` (== 8) bytes in the memory region pointed to by `s`
 to zero: this will effectively zero-out all fields of `*s`, as well as any padding.
 Clang optimizes this both on x86 and ARM.
 GCC and MSVC both refuse to optimize, and actually slightly worsen the generated assembly.
*/
void foo4(struct S* s)
{
    memset(s, 0, sizeof *s);
    s->x = 1;
    s->y = 2;
    s->z = 3;
}

/* 
 "But what if we...?" yes, that's right: in order to get portable code while ensuring that it 
 is optimized both by Clang and GCC, the best course of action is to call foo3() followed by foo2()!
 We have achieved PERFORMANCE!
 MSVC still refuses to optimize this, and GCC on ARM again prefers the "component-wise" approach. 
*/
void foo5(struct S* s)
{
    foo3(s);
    foo4(s);
}

/* 
This causes Clang to setup a look-up table on ARM, and it won't optimize on x86
*/
void foo6(struct S* s)
{
    *s = (struct S){};
    memset(s, 0, sizeof *s);
    s->x = 1;
    s->y = 2;
    s->z = 3;
}

/* 
Same as `foo6`, and also disrupts GCC from optimizing.
*/
void foo7(struct S* s)
{
    memset(s, 0, sizeof *s);
    *s = (struct S){};
    s->x = 1;
    s->y = 2;
    s->z = 3;
}