C++ -fno-strict-aliasing 的性能影响
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1225741/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Performance impact of -fno-strict-aliasing
提问by Carlos
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（或其他编译器中的等效项）中指定 -fno-strict-aliasing 而导致性能下降？
回答by Resistor
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.
它会因编译器而异，因为不同的编译器以不同的攻击级别实现它。GCC 对此相当激进：启用严格别名将使其认为“显然”等同于人类的指针（如 , foo *a; bar *b = (bar *) a;）不能别名，这允许进行一些非常激进的转换，但显然会破坏不仔细编写的代码。出于这个原因，Apple 的 GCC 默认禁用严格别名。
LLVM, by contrast, does not even havestrict 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.
相比之下，LLVM 甚至没有严格的别名，虽然它是计划中的，但开发人员表示他们计划将其作为后备案例来实现，因为其他任何东西都无法判断等效性。在上面的例子中，它仍然会判断 a 和 b 相等。如果它不能以任何其他方式确定它们的关系，它只会使用基于类型的别名。
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.
根据我的经验，严格别名对性能的影响主要与循环不变代码运动有关，其中类型信息可用于证明循环内加载不能对正在迭代的数组进行别名，从而允许将它们拉出循环。天啊。
回答by nielsj
What I can tell you from experience (having tested this with a large project on PS3, PowerPC being an architecture that due to it's many registers can actually benefit from SA quite well) is that the optimizations you're going to see are generally going to be very local (scope wise) and small. On a 20MB executable it scraped off maybe 80kb of the .text section (= code) and this was all in small scopes & loops.
我可以从经验告诉你（在 PS3 上用一个大型项目对此进行了测试，PowerPC 是一种架构，由于它有很多寄存器实际上可以从 SA 中受益）是你将看到的优化通常会非常本地（范围明智）和小。在一个 20MB 的可执行文件上，它可能刮掉了 80kb 的 .text 部分（= 代码），这一切都在小范围和循环中。
This option can make your generated code a bit more lightweight and optimized than it is right now (think in the 1 to 5 percent range), but do not expect any big results. Hence, the effect of using -fno-strict-aliasing is probably not going to be a big influence on your performance, at all. That said, having code that requires -fno-strict-aliasing is a suboptimal situation at best.
这个选项可以让你生成的代码比现在更轻量和优化（想想在 1% 到 5% 的范围内），但不要期望任何大的结果。因此，使用 -fno-strict-aliasing 的效果可能根本不会对您的性能产生重大影响。也就是说，拥有需要 -fno-strict-aliasing 的代码充其量只是一种次优情况。
回答by SzymonPajzert
Here is a link to study conducted in 2004: http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1124&context=ecetrconcerning, among others, strict aliasing impact on code performance. Figure 2.5 shows relative improvement of 3% to 10%.
以下是 2004 年进行的研究的链接：http: //docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1124&context=ecetr，其中涉及严格的别名对代码性能的影响。图 2.5 显示了 3% 到 10% 的相对改进。
Researchers' explanation of performance degradation:
研究人员对性能下降的解释：
From inspecting the assembly code, we found that the degradation is an effect of the register allocation algorithm. GCC implements a graph coloring register allocator[2, 3]. With strict aliasing, the live ranges of the variables become longer, leading to high register pressure and ‘ spilling. With more conservative aliasing, the same variables incur memory transfers at the end of their (shorter) live ranges as well.
[2] Peter Bergner, Peter Dahl, David Engebretsen, and Matthew T. O'Keefe. Spill code minimization via interference region spilling. In SIGPLAN Conference on Programming Language Design and Implementation, pages 287–295, 1997.
[3] Preston Briggs, Keith D. Cooper, and Linda Torczon. Improvements to graph coloring register allocation. ACM Transactions on Programming Languages and Systems, 16(3):428–455, May 1994.
通过检查汇编代码，我们发现性能下降是寄存器分配算法的影响。GCC 实现了一个图形着色寄存器分配器[2, 3]。使用严格的别名，变量的有效范围变长，导致高注册压力和“溢出”。使用更保守的别名，相同的变量也会在其（较短的）生命周期结束时引起内存传输。
[2] Peter Bergner、Peter Dahl、David Engebretsen 和 Matthew T. O'Keefe。通过干扰区域溢出来最小化溢出代码。在 SIGPLAN 编程语言设计和实现会议上，第 287-295 页，1997。
[3] 普雷斯顿·布里格斯、基思·D·库珀和琳达·托克宗。图形着色寄存器分配的改进。ACM 编程语言和系统交易，16(3):428–455，1994 年 5 月。
