是否有编译器能够提出绝对需要程序员批准的优化建议？

Question

如果我们让人类参与循环，编译器是否可以做更多严格的语义等效优化？

有一些潜在的优化被编译器彻底抛弃，因为它们可能在语义上不等价。

然而，它们可能也很好，那么为什么不尝试检测并建议它们呢？检测可能涉及两个阶段的过程：编译时分析阶段和运行时分析阶段。

错误、警告和...建议？

编译器已经对“警告”做了类似的事情，从某种意义上说，它们在每次编译期间都会被汇集起来，并永远保留在列表中，直到您将它们解决到编译器满意为止。为什么不设置一个“建议”或“建议的优化”部分，以类似的方式运行，并且有可能提高应用程序的性能？

如果编译器要分析布尔表达式的复杂性、估计的运行时间、单个操作数为真与假的可能性等，那么它可以创建一个建议列表，例如表达式操作数的更好顺序，并提供建议作为给程序员的列表。然后，程序员可以单独处理它们，并决定忽略它们，或者让代码编辑器实现建议。

优化布尔表达式操作数顺序

考虑“短路逻辑表达式的优化”。因为操作数的顺序影响哪个操作数可能被“短路”（即不被调用），所以简单布尔表达式（即 A && B && C）中操作数的顺序是（我认为）编译器保持不变，以避免在任何操作数有副作用时引入未知的副作用。

考虑一下：

char c = reader.ReadChar(); //Stream bs; const string NEWLINE;
while (!IsStringPresent( c, bs, NEWLINE ) && c != ',')

由于比较字符（更快/更简单），因此它应该在表达式中排在第一位，以便短路逻辑可以避免在遇到逗号时调用 IsStringPresent。在这种情况下，逗号（每行有多个）也确实会比新行序列更频繁地遇到。

char c = reader.ReadChar(); //Stream bs; const string NEWLINE;
if (c != ',' && !IsStringPresent( c, bs, NEWLINE )) //faster for short-circuit; plus ',' is encountered more often than newline

总结

客观地，可以根据“A 与 B 触发短路的频率”和“计算 A 与 B 的成本，有利于短路”来确定任何表达式“A && B”的最佳操作数顺序。更昂贵的电路”。如果编译器可以在编译时、运行时或两者中确定其中任何一个的近似值，那么它可以确定特定表达式可能不是最佳的，并且它可以为程序员创建建议的更改来实现。

今天有编译器做这样的事情吗？如果没有，为什么？

Answer 1

我的观点是，仅仅因为程序员认为可以，就允许优化器短路函数调用，这会导致无法追踪的错误。每次编译时都会询问吗？我不知道；听起来像这样的事情会有很多问题。

Answer 2

我的回答是“可能”，但是“这是我们真正想做的吗？”

也许您建议编译器检测到可能的同构，但不确定是否是同构，因此它询问程序员“这是同构吗”，但无论如何“如果是这样，如果我应用它，会导致你认为更快的代码吗？”

然而，我的想法更像是这样的：“嘿程序员，如果我们能做到这一点，我们会得到更快的代码，但是，语义是不同的！我们必须加强这个函数的前提条件来进行这种优化可以吗？

加强一个前置条件可能还可以，哎呀，程序员可能根本就没有写前置条件。如果程序员说“当然，没关系”，而程序员错了，那么运气好的话，测试就会发现“前置条件失败”的问题。

Answer 3

你问的主要是程序员的任务。在某种程度上，可以扩展诸如静态分析工具或重构工具之类的工具来完成您想要的任务。

编译器的任务是在标准规则范围内（尽可能）。对于某些（激进的）优化，编译器确实提供了特定的标志，可以传递这些标志来启用/禁用它们
例如矢量化、内联、过程间等——这些优化很难手工完成。

重新排序（在您提到的示例中）受到 C、C++ 标准的限制，因为它们可能会更改程序的语义。在操作没有副作用的情况下，可以对它们重新排序，并且编译器在指令调度期间执行此类操作（在 clang++ 和 g++ 中的 -O2 处），但我不确定有多少其他编译器这样做。