-fno-strict-aliasing的性能影响
是否有任何研究或一组基准测试显示由于在GCC中指定-fno-strict-aliasing（或其他编译器中的等效项）而导致的性能下降？
从编译器到编译器会有很多不同，因为不同的编译器会以不同的攻击级别实现它。 GCC对此非常积极：启用严格别名会使它认为“明显”等同于人类的指针（如in， foo* a; bar * b; b = (foo*)a; ）不能别名，这允许一些非常积极的转换，但显然可以打破非仔细编写的代码。 出于这个原因，Apple的GCC默认禁用严格别名。
相比之下，LLVM甚至没有严格的别名，并且在计划时，开发人员已经表示他们计划将其作为一个后备案例来实现，而其他任何东西都无法判断等价。 在上面的例子中，它仍将判断a和b等价物。 如果它无法以任何其他方式确定它们之间的关系，它将只使用基于类型的别名。
根据我的经验，严格别名的性能影响主要与循环不变代码运动有关，其中类型信息可用于certificate循环加载不能对迭代的数组进行别名，允许它们被拉出循环。 因人而异。
我从经验中可以告诉你的是（在PS3上测试了这个大型项目，PowerPC是一个架构，由于它的许多寄存器实际上可以从SA中获益很好），你将会看到的优化通常是非常本地（范围明智）和小。 在一个20MB的可执行文件上，它可以删除80kb的.text段（=代码），这些都是在小范围和循环中。
此选项可以使您生成的代码比现在更轻量级和优化（想想在1％到5％的范围内），但不要指望任何重大结果。 因此，使用-fno-strict-aliasing的效果可能根本不会对您的性能产生很大影响。 也就是说，拥有需要-fno-strict-aliasing的代码充其量只是次优的情况。
以下是2004年进行的研究链接： http ： //docs.lib.purdue.edu/cgi/viewcontent.cgi？article = 1124＆context = egtr，其中包括严格的别名对代码性能的影响。 图2.5显示了3％至10％的相对改善。
研究人员对性能下降的解释：
通过检查汇编代码，我们发现降级是寄存器分配算法的影响。 GCC实现了图着色寄存器分配器[2,3]。 通过严格的混叠，变量的有效范围变得更长，导致高的套准压力和“溢出”。 使用更保守的别名，相同的变量也会在其（较短的）有效范围结束时产生内存传输。
[2] Peter Bergner，Peter Dahl，David Engebretsen和Matthew T. O’Keefe。 通过干扰区域溢出来溢出代码最小化。 在SIGPLAN会议编程语言设计和实现，第287-295页，1997年。
[3] Preston Briggs，Keith D. Cooper和Linda Torczon。 图着色寄存器分配的改进。 ACM Transactions on Programming Languages and Systems，16（3）：428 – 455，1994年5月。