-fno-strict-aliasing的性能影响

是否有任何研究或一组基准测试显示由于在GCC中指定-fno-strict-aliasing(或其他编译器中的等效项)而导致的性能下降？

1> 小智..：

---

从编译器到编译器,它会有很大的不同,因为不同的编译器会以不同的攻击级别实现它.GCC对此非常咄咄逼人:启用严格别名会导致它认为"明显"等同于人类(如in foo *a; bar *b = (bar *) a;)的指针不能别名,这允许一些非常积极的转换,但显然可以打破非小心写码.出于这个原因,Apple的GCC默认禁用严格别名.

相比之下,LLVM甚至没有严格的别名,并且在计划时,开发人员已经表示他们计划将其作为一个后备案例来实现,而其他任何东西都无法判断等价.在上面的例子中,它仍将判断a和b等价物.如果它无法以任何其他方式确定它们之间的关系,它将仅使用基于类型的别名.

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

---

LLVM的方法听起来对我来说是正确的

2> nielsj..：

---

我可以从经验告诉你(在PS3上测试了这个大型项目,PowerPC是一个架构,由于它的许多寄存器实际上可以从SA中获益很好)是你将看到的优化通常会非常本地(范围明智)和小.在一个20MB的可执行文件上,它可以删除80kb的.text部分(=代码),这些都是在小范围和循环中.

此选项可以使您生成的代码比现在更轻量级和优化(想想在1%到5%的范围内),但不要指望任何重大结果.因此,使用-fno-strict-aliasing的效果可能根本不会对您的性能产​​生很大影响.也就是说,拥有需要-fno-strict-aliasing的代码充其量只是次优的情况.

---

在许多情况下,忽略严格别名规则的代码可以更容易阅读,即使在编译器上(可能因为配置)不能特别有效地优化memcpy(),也会产生不错的性能.如果严格别名不会产生有意义的性能提升,那么与编写可读代码和禁用严格别名相比,是不是写出了丑陋的繁琐代码次优？

3> 小智..：

---

以下是2004年进行的研究链接:http://docs.lib.purdue.edu/cgi/viewcontent.cgi？article = 1124&context = ecetr,其中包括严格的别名对代码性能的影响.图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月.