内联 asm 编译器屏障（内存破坏器）算作外部函数还是静态函数调用？

Question

基本事实的介绍/确认

众所周知，使用 GCC 风格的 C 和 C++ 编译器，您可以将内联汇编与“内存”破坏器一起使用：

asm("":::"memory");

为了防止（大多数）代码经过它重新排序，充当（线程本地）“内存屏障”（例如，为了与异步信号交互）。

注意：这些“编译器屏障”不会实现线程间同步。

它相当于调用非内联函数，可能会读取所有可以在当前范围之外读取的对象并更改所有可以更改的对象（非 const 对象）：

int i;

void f() {
   int j = i;
   asm("":::"memory"); // can change i
   j += i; // not j *= 2
   // ... (assume j isn't unused)
}

本质上它与调用单独编译的 NOP 函数相同，只是非内联 NOP 函数调用稍后 (1) 内联，因此没有任何内容可以从中幸存。

(1) 说，经过编译器中间传递，经过分析

所以这里的j 不能更改，因为它是本地的，并且仍然是旧i 值的副本，但i 可能已经更改，所以编译几乎与以下内容相同：

volatile int vi;

int f2() {
   int j = vi;
   ; // can "change" vi
   j += vi; // not j *= 2
   return j;
}

需要两次读取vi（出于不同的原因），因此编译器不会将其更改为2*vi。

到目前为止，我的理解是否正确？ （我想是的。否则这个问题没有意义。）

真正的问题：外部还是静态

以上只是序言。我遇到的问题是静态变量，可能调用静态函数（或 C++ 等效的匿名命名空间）：

内存破坏者能否访问无法通过非静态函数访问的静态数据，并调用无法通过其他方式调用的静态函数，因为这些函数在链接阶段都不可见，从其他模块，如果它们没有在 asm 指令的输入参数中明确命名？

static int si;

int f3() {
   int j = si;
   asm("":::"memory"); // can access si?
   j += si; // optimized to j = si*2; ?
   return j;
}

[注意：静态的使用有点模糊。建议是 TU 的边界很重要，静态变量是 TU 私有的，但我没有描述它是如何被操纵的。让我们假设它确实在那个 TU 中被操纵，或者编译器可能会假设它实际上是一个常量。]

换句话说，“clobber”是否相当于调用：

• 一个外部 NOP 函数，它不能直接命名 si，也不能以任何间接方式访问它，因为 TU 中的任何函数都不能传递 si 的地址，或者使 si间接可修改
• 一个本地定义的NOP函数，可以访问si

?

额外问题：全局优化

如果答案是在这种情况下静态变量不被视为外部变量，那么在一次编译程序时会产生什么影响？更具体地说：

在整个程序的全局编译过程中，通过对变量值的全局分析和推断，知道例如全局变量永远不会被修改（或永远不会分配负值......），除非可能在asm“clobber”，优化器的输入？

也就是说，如果非静态i仅在一个TU中命名，那么即使有asm语句，是否可以将其优化为静态int？在这种情况下，是否应该将全局变量明确列为 clobbers？

Answer 1

它相当于调用非内联函数，可能会读取所有可以在当前范围之外读取的对象并更改所有可以更改的对象（非 const 对象）：

没有。

编译器可以决定内联同一编译单元中的任何函数（然后，如果该函数不是static，还为其他编译单元中的调用者提供单独的“未内联”副本，以便链接器可以找一个）;并且通过链接时代码优化/链接时代码生成，链接器可以决定内联不同编译单元中的任何函数。当前不可能内联任何函数的唯一情况是当它位于共享库中时；但目前存在此限制，因为操作系统目前不具备“加载时优化”的能力。

换句话说；任何功能出现任何类型的障碍都是优化器弱点的意外副作用，并且不能保证；因此不能/不应依赖。

真正的问题：内联汇编

有5种可能性：

a) 编译器理解所有的程序集，并且能够检查内联程序集并确定什么是/没有被破坏；没有破坏列表（也不需要一个）。在这种情况下（取决于编译器/优化器的先进程度），编译器可能能够确定诸如“此内存区域可能被破坏但该内存区域不会被破坏”之类的事情，并避免从重新加载数据的成本未被破坏的内存区域。

b) 编译器不理解任何程序集并且没有破坏列表，因此编译器必须假设所有内容都会被破坏；这意味着编译器必须在执行内联汇编之前生成将所有内容（例如寄存器中当前使用的值等）保存到内存并在之后重新加载所有内容的代码，这将导致性能极差。

c) 编译器不理解任何程序集，并希望程序员提供一个 clobber 列表以避免（部分）不得不假设所有内容都会被破坏的性能灾难。

d) 编译器理解一些程序集，但不是所有程序集，并且没有破坏列表。如果它不理解程序集，它会假定所有内容都可能已被破坏。

e) 编译器理解一些程序集，但不是所有程序集，并且确实有一个（可选的？）clobber 列表。如果它不理解程序集，它依赖于 clobber 列表（和/或如果没有 clobber 列表，则回退到“假设一切都被破坏”），如果它确实理解程序集，它会忽略 clobber 列表。

当然，使用“选项 c)”的编译器可以改进为使用“选项 e)”；并且使用“选项 e)”的编译器可以改进为使用“选项 a)”。

换句话说；对于“asm("":::"memory");”之类的任何类型的障碍的任何外观都是编译器“可改进”的意外副作用；因此不能/不应依赖。

总结

你提到的这些东西实际上都不是任何形式的障碍。这一切都只是“无意和不希望的优化失败”。

如果您确实需要屏障，则使用实际的屏障（例如“asm("mfence":::"memory");”。但是（除非您需要线程间同步并且不使用原子）您极有可能不需要屏障第一名。