C ++优化器将对Clock（）的调用重新排序是否合法？

C ++编程语言第4版，第225页显示：编译器可以对代码重新排序以提高性能，只要结果与简单执行顺序相同即可。某些编译器，例如处于发布模式的Visual C ++，将重新排序以下代码：

#include <time.h>
...
auto t0 = clock();
auto r  = veryLongComputation();
auto t1 = clock();

std::cout << r << "  time: " << t1-t0 << endl;

变成这种形式：

auto t0 = clock();
auto t1 = clock();
auto r  = veryLongComputation();

std::cout << r << "  time: " << t1-t0 << endl;

这样可以保证结果与原始代码不同（报告的时间为零与大于零的时间）。请参阅我的其他问题以获取详细示例。这种行为符合C ++标准吗？

编译器无法交换两个clock调用。t1必须在之后设置t0。这两个调用都是可观察到的副作用。只要观察结果与抽象机的可能观察结果一致，编译器就可以在这些可观察的结果之间甚至在可观察的副作用之间重新排序。

由于C ++抽象机不受形式上有限速度的限制，因此它可以veryLongComputation()在零时间内执行。执行时间本身并未定义为可观察到的效果。实际的实现可能与此匹配。

请注意，很多答案取决于C ++标准，而不是对编译器施加限制。

好吧，有个叫Subclause 5.1.2.3 of the C Standard [ISO/IEC 9899:2011]什么的状态：

在抽象机中，所有表达式均按语义指定的方式求值。如果实际实现可以推断出未使用表达式的值并且没有产生所需的副作用（包括由调用函数或访问易失性对象引起的副作用），则无需评估表达式的一部分。

因此，我真的怀疑这种行为-您所描述的行为-符合该标准。

此外，重组确实会对计算结果产生影响，但是，如果从编译器的角度来看，重组会存在于int main()世界中，并且在进行时间测量时会窥探到，要求内核提供当前时间，然后回到主要世界，外部世界的实际时间并不重要。clock（）本身不会影响程序和变量，程序行为也不会影响该clock（）函数。

时钟值用于计算它们之间的差异-这就是您要的。如果正在发生某种情况，那么从编译器的角度来看，两次测量之间就没有关系，因为您要求的是时钟差，并且两次测量之间的代码不会影响到整个过程。

但是，这不会改变所描述的行为非常令人不愉快的事实。

即使不准确的测量令人不快，它也可能变得更加糟糕甚至危险。

考虑以下从该站点获取的代码：

void GetData(char *MFAddr) {
    char pwd[64];
    if (GetPasswordFromUser(pwd, sizeof(pwd))) {
        if (ConnectToMainframe(MFAddr, pwd)) {
              // Interaction with mainframe
        }
    }
    memset(pwd, 0, sizeof(pwd));
}

正常编译后，一切正常，但是如果应用优化，则将优化memset调用，这可能会导致严重的安全漏洞。为什么会对其进行优化？这很简单；编译器再次思考main()并认为memset是死存储，因为此后pwd不使用该变量并且不会影响程序本身。

是的，这是合法的-如果编译器可以看到在clock()调用。

如果在veryLongComputation()内部执行任何不透明的函数调用，则否，因为编译器无法保证其副作用可以与以下情况的互换：clock()。

否则，可以互换。
这是您使用时间不是一流实体的语言所要付出的代价。

请注意，内存分配（例如new）可以归入此类，因为可以在不同的转换单元中定义分配函数，并且只有在当前转换单元已被编译后才可以对其进行编译。因此，如果您仅分配内存，则编译器将被迫将分配和释放视为所有情况clock()（包括内存障碍以及所有其他情况）的最坏情况障碍，除非它已经具有内存分配器的代码并且可以证明这是没有必要的。实际上，我认为没有任何编译器会实际查看分配器代码来尝试证明这一点，因此这些类型的函数调用实际上会成为障碍。

至少根据我的阅读，不，这是不允许的。该标准的要求是（§1.9/ 14）：

在与要评估的下一个完整表达式关联的每个值计算和副作用之前，对与一个完整表达式关联的每个值计算和副作用进行排序。

编译器可以自由重新排序的程度超出“按条件”规则（第1.9 / 1节）所定义的范围：

本国际标准对一致性实现的结构没有要求。特别是，它们不需要复制或模拟抽象机的结构。相反，需要遵循的实现来（仅）模拟抽象机的可观察行为，如下所述。

剩下的问题是有关行为（由编写的输出cout）是否是正式可观察到的行为。简短的答案是，是的（第1.9 / 8节）：

对符合标准的实现最低的要求是：
[...]
-在程序终止时，写入文件的所有数据应当与可能的结果，根据抽象的语义程序的执行将产生的一个。

至少在我阅读该书时，这意味着clock当且仅当它仍然产生与按顺序执行这些调用相同的输出时，与您的长计算的执行相比，可以重新排列对它们的调用。

但是，如果您想采取额外的步骤来确保正确的行为，则可以利用另一项规定（另请参见第1.9 / 8节）：

—严格根据抽象机的规则评估对易失对象的访问。

要利用此优势，您可以对代码进行一些修改，使其类似于：

auto volatile t0 = clock();
auto volatile r  = veryLongComputation();
auto volatile t1 = clock();

现在，而不是立足于标准的三个独立的部分，仍然只具有结论相当一定的答案，大家可以看一下只有一个句子，有一个绝对的某些答案-与此代码，重新排序用途的clock对比，长计算是明确禁止的。

假设该序列处于循环中，并且veryLongComputation（）随机抛出一个异常。那么将计算多少个t0和t1？它是否会预先计算随机变量并根据预先计算进行重新排序-有时会重新排序，有时则不会？

编译器是否足够聪明，以至于只知道内存读取就是从共享内存读取。读数是控制棒在核反应堆中移动了多远的量度。时钟调用用于控制它们的移动速度。

或者，时机正在控制哈勃望远镜镜的打磨。大声笑

移动时钟调用似乎太危险了，不能交给编译器编写者来决定。因此，如果合法，则该标准可能有缺陷。

海事组织。

这肯定是不容许的，因为它的变化，因为你已经注意到，该方案的observeable行为（不同的输出）（我不会进入该假设情况veryLongComputation()可能不消耗任何可测量时间-定的函数的名称，是大概不是这样。但是即使是这样，也没关系。你不会想到，这是允许的要重新排序fopen和fwrite，你会。

二者t0并t1在输出中使用t1-t0。因此，对于初始化表达式t0和t1必须执行，这样做必须符合所有标准的规则。使用了函数的结果，因此不可能优化函数调用，尽管它并不直接依赖于函数调用，t1反之亦然，因此人们可能会天真地认为将其移动是合法的，为什么不这样做呢？ 。也许在初始化之后t1，不依赖于计算吗？
但是，间接的结果（特别是计算需要花费时间，如果没有其他情况），这恰好是存在诸如“序列点”之类的原因之一。t1 当然取决于副作用veryLongComputation()

有三个“表达式结尾”序列点（加上三个“函数结尾”和“初始化程序的结尾” SP），并且在每个序列点处都保证将执行先前评估的所有副作用，并且没有副作用后续评估的效果尚未执行。
如果在这三个语句中四处移动，您将无法兑现这一承诺，因为未知所有被调用函数的可能副作用。仅当编译器可以保证将遵守承诺时，才允许对其进行优化。它不能，因为库函数是不透明的，它们的代码是不可用（也就是内部的代码veryLongComputation，必然在翻译单元已知的）。

但是，编译器有时确实具有关于库函数的“特殊知识”，例如某些函数将不会返回或可能会返回两次（认为exit或setjmp）。
但是，由于每个非空的，非平凡的函数（并且veryLongComputation从名称上来说都是非平凡的）都会消耗时间，clock因此实际上必须明确禁止具有其他方面不透明库函数的“特殊知识”的编译器知道这一点不仅可能而且会影响结果。

现在有趣的问题是，为什么编译器仍然这样做？我可以想到两种可能性。也许您的代码触发了“看起来像基准”启发式方法，并且编译器试图作弊，谁知道。这将不是第一次（想想SPEC2000 / 179.art，或者两个历史示例都是SunSpider）。另一种可能性是veryLongComputation()，您无意间调用了内部未定义的行为。在这种情况下，编译器的行为甚至是合法的。