功能代码对齐到16个字节

Question

Microsoft编译器似乎生成x64代码，其函数（与数据相对）对齐到16个字节，即除了目标文件中的last之外的每个函数都将其代码填充为0xCC（中断指令，可能是为了更容易调试）直到下一个16字节边界。

这是为什么？它真的能提高性能吗？如果是这样，怎么样？直观地说，如果出于缓存的原因，它应该稍微降低性能。

Answer 1

在大多数x86-64架构中，要执行的代码是通过16字节（see “Instruction fetch” sections）的对齐行从内存中获取的。这意味着如果目标是16字节的倍数，则传入分支将以最大数量的预取和解码指令开始。当执行没有从前面的代码转换（通过）到标签时，就像函数开始的情况一样，填充指令无关紧要，并且看起来对齐标签通常是一种收益。优化器通常会这样做，除非他们被告知优化代码大小（但是由于你在问题中陈述的原因，它仍然是一个损失：它降低了代码密度并使各种缓存效率降低）。

也可以通过下降（通常是循环的开始）来对齐可以到达的分支目的地。在这种情况下，权衡甚至不太可能是有利的，因为如果目的地没有对齐，在堕落期间需要执行一些nop指令。创建长nop指令的技巧比多个短nop指令更快地解码，但这仍然无益于平均，并且优化编译器仅在明确指示（例如GCC的-falign-loops选项时执行此操作，而不是{ {1}}。向下滚动到this page上对-falign-functions选项的讨论。