c++ - 函数参数的编译器优化

Question

函数参数放在堆栈上，但编译器可以通过使用可选寄存器来优化此任务。如果只有 1-2 个参数，而不是当有 256 个参数时(不是那个人想要拥有最大数量的参数)，这种优化就会开始是有道理的。

如何找出特定编译器(如 gcc)的参数限制(参数数量)，从而确定将使用此优化？

Answer 1

Function parameters are placed on the stack, but compilers can optimize this task by the use of optional registers.

正如 FrankH 在他的评论中所说以及我将在我的回答中所说的那样，所讨论系统的应用程序二进制接口(interface)决定了如何将参数传递给函数 - 这称为该平台的调用约定。

更复杂的是，x86 32 位实际上有几个。这是历史原因，因为当 Win32 出现时，每个人都疯狂地做着不同的事情。

所以，是的，您可以通过以这种方式编写函数调用来“优化”，但不，您不应该这样做。您应该遵循平台的标准。因为诚实的事实是，堆栈访问的速度可能不会将您的代码减慢到您需要与系统上的其他人保持二进制不兼容的程度。

为什么需要 ABI/标准调用约定？好吧，就使用处理器寄存器、堆栈等而言，应用程序必须就什么意味着什么以及它应该去哪里达成一致。如果一个函数决定它的所有参数都在寄存器中，而另一个函数决定一些参数在堆栈中，它们将如何互操作？此外，您可能会遇到术语暂存寄存器，表示那些您不必恢复的寄存器。如果您调用一个函数并希望它单独保留一些寄存器，会发生什么情况？

无论如何，至于你要求什么，这里有一些 ABI 文档:

• 差异between x86 and x64 on windows .
• x86_64 ABI用于类 Unix 平台。
• 维基百科的 x86 calling conventions .
• 关于 compiler calling conventions 的文件.

最后一个是我最喜欢的。引用它:

In the days of the old DOS operating system, it was often possible to combine development tools from different vendors with few compatibility problems. With 32-bit Windows, the situation has gone completely out of hand. Different compilers use different data representations, different function calling conventions, and different object file formats. While static link libraries have traditionally been considered compiler-specific, the widespread use of dynamic link libraries (DLL's) has made the distribution of function libraries in binary form more common.

因此，无论您尝试通过修改函数调用方法来进行优化，都不要这样做。寻找另一种优化方法。分析您的代码。如果您认为它有帮助，请研究您为编译器 (-OX) 进行的编译器优化，并转储程序集以检查速度是否真的那么重要