编译器可以基于 assert(...) 表达式/合同进行优化吗？答案

【问题标题】：may the compiler optimize based on assert(...) expressions/contracts?编译器可以基于 assert(...) 表达式/合同进行优化吗？
【发布时间】：2013-08-12 19:51:59
【问题描述】：

http://dlang.org/expression.html#AssertExpression

关于assert(0)：“编译的优化和代码生成阶段可能会假设它是无法访问的代码。”

相同的文档声称 assert(0) 是一个“特殊情况”，但有几个原因。

D 编译器能否基于合约和其他地方生成的通用assert-ions 进行优化？

^{_{（好像我需要另一个享受in{} 和out{} 构造的理由，但知道这样写肯定会让我更加头晕目眩他们可以让事情变得更糟）}}

【问题讨论】：

标签： compiler-optimization d

【解决方案1】：

理论上，是的，在实践中，我认为不会，特别是因为断言在 dmd -release 上到达优化器之前就被杀死了。我不确定 gdc 和 ldc，但我认为他们共享这部分代码。

规范的特殊情况参考顺便说一句，assert(0) 仍然存在，以某种形式，带有 -release 编译标志。它在那里被翻译成非法指令（asm {hlt;} - x86 上的非内核程序不允许使用它，因此它会在命中它时出现段错误），而所有其他断言完全被排除在代码之外-释放模式。

【讨论】：

如果你用D写内核，这个hlt指令不是问题吗？
也许吧，但无论如何它应该是无法访问的，所以你不应该在调试模式之外执行它。

【解决方案2】：

GDC 确实基于断言进行了优化。 if 条件可以生成更好的代码，甚至会导致不必要的代码消失。然而，不幸的是，目前它的实现方式是整个断言可以在发布构建模式下消失，因此编译器永远不会看到有益的 if 条件信息，实际上在发布时生成的代码比在调试模式下更糟糕！具有讽刺意味。我不得不承认，我只用 body 中的断言中的 if 条件查看了这种效果，我还没有检查 in 和 out 块有什么效果。可以基于命令行开关 iirc 关闭 in-和 out- 等合约块，因此它们甚至没有被编译，我认为这可能意味着编译器甚至不看它们。所以这是可能影响代码生成的另一件事，我没有看过。但是这里有一个我非常希望看到的功能，即断言条件中的 if 条件真值（检查断言条件的表达式中是否没有副作用代码）始终可以注入编译器作为一个假设，就好像即使在发布模式下也有一个 if 语句。这将涉及假装您刚刚看到一个 if ( xxx )，但在发布模式下抑制了测试的实际代码生成，并且随后的代码感受到了已知真值、值范围限制等的有益效果。

【讨论】：