-fno-strict-aliasing 的性能影响

Performance impact of -fno-strict-aliasing(-fno-strict-aliasing 的性能影响)

问题描述

是否有任何研究或一组基准显示性能由于在 GCC 中指定 -fno-strict-aliasing(或在其他编译器中等效)?

Is there any study or set of benchmarks showing the performance degradation due to specifying -fno-strict-aliasing in GCC (or equivalent in other compilers)?

推荐答案

它会因编译器而异，因为不同的编译器以不同的攻击级别实现它.GCC 对此相当激进:启用严格别名会导致它认为指针明显"等同于人类(如 foo *a; bar *b = (bar *) a;) 不能使用别名，这允许进行一些非常激进的转换，但显然会破坏非精心编写的代码.由于这个原因，Apple 的 GCC 默认禁用严格别名.

It will vary a lot from compiler to compiler, as different compilers implement it with different levels of aggression. GCC is fairly aggressive about it: enabling strict aliasing will cause it to think that pointers that are "obviously" equivalent to a human (as in, foo *a; bar *b = (bar *) a;) cannot alias, which allows for some very aggressive transformations, but can obviously break non-carefully written code. Apple's GCC disables strict aliasing by default for this reason.

相比之下，LLVM 甚至没有 严格的别名，而且，虽然这是计划中的，但开发人员表示他们计划在没有其他方法可以判断时将其作为备用案例来实现等价.在上面的例子中，它仍然会判断 a 和 b 等价.如果无法以任何其他方式确定它们的关系，它只会使用基于类型的别名.

LLVM, by contrast, does not even have strict aliasing, and, while it is planned, the developers have said that they plan to implement it as a fall-back case when nothing else can judge equivalence. In the above example, it would still judge a and b equivalent. It would only use type-based aliasing if it could not determine their relationship in any other way.

根据我的经验，严格别名的性能影响主要与循环不变的代码运动有关，其中类型信息可用于证明循环内加载不能对正在迭代的数组进行别名，允许它们拉出循环.YMMV.

In my experience, the performance impact of strict aliasing mostly has to do with loop invariant code motion, where type information can be used to prove that in-loop loads can't alias the array being iterated over, allowing them to be pulled out of the loop. YMMV.

这篇关于-fno-strict-aliasing 的性能影响的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！