c++ - 优化 volatile 堆栈变量的存储/构造是否合法？

Question

我注意到在某些情况下，clang 和 gcc 优化了在堆栈上声明的 volatile struct 的构造或赋值。例如下面的代码:

struct nonvol2 {
    uint32_t a, b;
};

void volatile_struct2()
{
    volatile nonvol2 temp = {1, 2};
}

Compiles在 clang 上:

volatile_struct2(): # @volatile_struct2()
  ret

另一方面，gcc 不会删除存储，尽管它确实将两个隐含存储优化为一个存储:

volatile_struct2():
        movabs  rax, 8589934593
        mov     QWORD PTR [rsp-8], rax
        ret

奇怪的是，clang 不会将 volatile 存储优化为单个 int 变量:

void volatile_int() {
    volatile int x = 42;
}

编译为:

volatile_int(): # @volatile_int()
  mov dword ptr [rsp - 4], 1
  ret

此外，具有 1 个成员而不是 2 个成员的结构不会被优化掉。

尽管 gcc 在这种特殊情况下没有删除构造，但在 struct 成员本身被声明为 volatile 的情况下，它可能会进行更积极的优化，而不是比构造点上的 struct 本身:

typedef struct {
    volatile uint32_t a, b;
} vol2;

void volatile_def2()
{
    vol2 temp = {1, 2};
    vol2 temp2 = {1, 2};
    temp.a = temp2.a;
    temp.a = temp2.a;
}

简单地编译成一个简单的ret。

虽然删除这些几乎不可能通过任何合理过程观察到的存储似乎是完全“合理的”，但我的印象是，在标准 volatile 中，加载和存储被假定为程序的可观察行为(除了调用 IO 函数)，句号。这意味着它们不受“好像”删除的影响，因为根据定义，它会改变程序的可观察行为。

我是不是错了，还是 clang 违反了这里的规则？也许 construction 被排除在必须假设 volatile 有副作用的情况之外？

Answer 1

从标准的角度来看，不要求实现记录任何对象在内存中的物理存储方式。即使实现记录了使用 unsigned char* 类型的指针访问特定类型对象的行为，实现也将被允许以其他方式物理存储数据，然后使用字符代码基于读取和写入适本地调整行为。

如果一个执行平台指定了抽象机器对象和 CPU 所见的存储之间的关系，并定义了访问某些 CPU 地址可能会触发编译器不知道的副作用的方式，那么一个适合低质量的编译器该平台上的 -level 编程应生成代码，其中 volatile 限定对象的行为与该规范一致。该标准并未尝试强制所有实现都适用于低级编程(或任何其他特定目的)。

如果自动变量的地址从不暴露给外部代码，volatile 限定符只需要有两个作用:

1. 如果在函数内调用 setjmp，编译器必须做任何必要的事情来确保 longjmp 不会破坏任何 volatile 的值 限定的对象，即使它们是在 setjmp 和 longjmp 之间编写的。如果没有限定符，在 setjmp 和 longjmp 之间写入的对象的值在执行 longjmp 时将变得不确定。

2. 允许编译器假定任何没有副作用的循环将运行完成的规则​​不适用于在循环内访问 volatile 对象的情况，无论实现是否定义可以观察到此类访问的任何方式。

除非在那些情况下，as-if 规则将允许编译器以与物理机无关的方式在抽象机中实现 volatile 限定符。