严格别名规则背后的基本原理是什么？

Question

我目前想知道严格别名规则背后的基本原理。我知道在 C 中不允许某些别名，其目的是允许优化，但令我惊讶的是，在定义标准时，这是优于跟踪类型转换的首选解决方案。

因此，显然以下示例违反了严格的别名规则：

uint64_t swap(uint64_t val)
{
    uint64_t copy = val;
    uint32_t *ptr = (uint32_t*)© // strict aliasing violation
    uint32_t tmp = ptr[0];
    ptr[0] = ptr[1];
    ptr[1] = tmp;
    return copy;
}

我可能错了，但据我所知，编译器应该能够完美而轻松地追踪类型转换并避免对显式转换的类型进行优化（就像它避免对相同类型的指针进行此类优化一样) 在使用受影响的值调用的任何内容上。

那么，我错过了哪些严格别名规则的问题，编译器无法轻松解决以自动检测可能的优化）？

Answer 1

由于在此示例中，所有代码对编译器都是可见的，因此编译器可以假设性地确定请求的内容并生成所需的汇编代码。然而，在理论上不需要严格的别名规则的一种情况的演示并不能证明不需要它的其他情况。

考虑代码是否包含：

foo(&val, ptr)

foo 的声明是void foo(uint64_t *a, uint32_t *b);。然后，在可能位于另一个翻译单元中的foo 内部，编译器将无法知道a 和b 指向同一对象的（部分）。

那么有两种选择：一，语言可能允许别名，在这种情况下，编译器在翻译foo时，不能根据*a和*b不同的事实进行优化。例如，每当向*b 写入内容时，编译器必须生成汇编代码以重新加载*a，因为它可能已更改。不允许进行优化，例如在使用 *a 时将其副本保存在寄存器中。

第二个选择，二，是禁止别名（特别是，如果程序这样做，则不定义行为）。在这种情况下，编译器可以根据*a 和*b 不同的事实进行优化。

C 委员会选择了选项二，因为它提供了更好的性能，同时不会过度限制程序员。

Answer 2

它允许编译器优化变量重新加载，而不需要你限制你的指针。

例子：

int f(long *L, short *S)
{
    *L=42;
    *S=43;
    return *L;
}

int g(long *restrict L, short *restrict S)
{
    *L=42;
    *S=43;
    return *L;
}

编译时在 x86_64 上禁用严格别名 (gcc -O3 -fno-strict-aliasing)：

f:
        movl    $43, %eax
        movq    $42, (%rdi)
        movw    %ax, (%rsi)
        movq    (%rdi), %rax ; <<*L reloaded here cuz *S =43 might have changed it
        ret
g:
        movl    $43, %eax
        movq    $42, (%rdi)
        movw    %ax, (%rsi)
        movl    $42, %eax     ; <<42 constant-propagated from *L=42 because *S=43 cannot have changed it  (because of `restrict`)
        ret

在 x86_64 上使用 gcc -O3（隐含 -fstrict-alising）编译：

f:
        movl    $43, %eax
        movq    $42, (%rdi)
        movw    %ax, (%rsi)
        movl    $42, %eax   ; <<same as w/ restrict
        ret
g:
        movl    $43, %eax
        movq    $42, (%rdi)
        movw    %ax, (%rsi)
        movl    $42, %eax
        ret

https://gcc.godbolt.org/z/rQDNGt

当您处理大型数组时，这会很有帮助，否则可能会导致大量不必要的重新加载。

Answer 3

指定的编程语言支持标准化委员会成员认为合理的常识性实践。使用非常不同类型的不同指针给同一个对象起别名被认为是不合理的，并且编译器不应该不遗余力地使之成为可能。

这样的代码：

float f(int *pi, float *pf) {
  *pi = 1;
  return *pf;
}

当pi 和pf 使用相同的地址时，其中*pf 是为了重新解释最近写入的*pi 的位，被认为是不合理因此是可敬的委员会成员（以及在他们之前的 C 语言设计者）认为在一个稍微复杂的示例中要求编译器避免常识性程序转换是不合适的：

float f(int *pi, double *pf) {
  (*pi)++;
  (*pf) *= 2.;
  (*pi)++;
}

这里允许两个指针指向同一个对象的极端情况会使增量融合无效的任何简化；假设没有发生这种别名，则允许将代码编译为：

float f(int *pi, double *pf) {
  (*pf) *= 2.;
  (*pi) += 2;
}

Answer 4

N1570 p6.5p7 的脚注清楚地说明了该规则的目的：说明事物何时可能出现别名。至于为什么要编写规则以禁止像您这样的构造不涉及所写的别名（因为所有使用uint32_t* 的访问都是在明显从uint64_t，这很可能是因为标准的作者认识到，任何真正努力产生适合低级编程的高质量实现的人都会支持像你这样的结构（作为“流行的扩展”），无论标准与否强制它。同样的原则在以下结构中显得更加明确：

unsigned mulMod65536(unsigned short x, unsigned short y)
{ return (x*y) & 65535u; }

根据基本原理，普通实现将以等同于无符号算术的方式处理对短无符号值的操作即使结果介于 INT_MAX+1u 和 UINT_MAX 之间，除非适用某些条件.当结果被强制转换为unsigned 时，不需要有一个特殊的规则来使编译器将涉及短无符号类型的表达式视为无符号，因为-根据标准的作者--commonplace implementations 即使没有这样的规则。

该标准从未打算完全指定声称适用于任何特定目的的高质量实施的所有内容。实际上，它甚至不要求实现适用于任何有用的目的（理由甚至承认质量如此差的“符合”实现的可能性，除了单个人为的和无用的程序之外无法有意义地处理任何东西） .