未知的编译器“优化”毫无意义
我正在查看用 Visual Studio 2008 编译的一些代码的反汇编，我发现整个代码中有一些奇怪的“优化”，这些优化在调用函数和传递参数时不太有意义。例如，以下代码输出以下反汇编结果：
代码：
int version;
int result = canParse(code, &version);`
反汇编：
003CE9FA push eax ; version
003CE9FB push ecx ; code
003CE9FC mov ecx, [esp+50h+code] ; AbcParser *
003CEA00 mov eax, esp
003CEA02 mov [eax], ecx
003CEA04 call avmplus::AbcParser::canParse(avmplus::ScriptBuffer,int *)
在这种情况下，push ecx 在堆栈上腾出了一些空间，即然后被[esp+50h+code]覆盖。
为什么编译器要这样做？
它不节省空间。 （使用 mov ecx, [esp+50h+code]; push ecx 会占用更少的空间。）据我所知，它不会节省时间。 （执行我刚才提到的两条指令不是更快吗？）
此外，在 canParse 中使用时，ecx 和 eax 都会被覆盖。
I was looking at the disassembly of some code I compiled with Visual Studio 2008, and I see some weird "optimizations" litter throughout the code that don't quite make sense when functions are called and parameters are passed. For example, the following code outputs the following disassembly:
Code:
int version;
int result = canParse(code, &version);`
Disassembly:
003CE9FA push eax ; version
003CE9FB push ecx ; code
003CE9FC mov ecx, [esp+50h+code] ; AbcParser *
003CEA00 mov eax, esp
003CEA02 mov [eax], ecx
003CEA04 call avmplus::AbcParser::canParse(avmplus::ScriptBuffer,int *)
In this case, push ecx makes some space on the stack that is then overwritten by [esp+50h+code].
Why does the compiler do this?
It doesn't save space. (It would take less room to have mov ecx, [esp+50h+code]; push ecx.) It doesn't save time, as far as I know. (Wouldn't executing the two instructions I just mentioned be faster?)
Also, both ecx and eax are overwritten when used within canParse.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正如 @Radek Pro-Grammer 在他的评论中建议的那样，即使有更多看似无用的指令，代码也可能会在更少的时钟周期内运行。如今的处理器要复杂得多，具有流水线、预取队列、缓存、超标量设计等，因此优化可以相当......大胆。 :)
As @Radek Pro-Grammer suggested in his comment, even if there are more instructions which seem useless, the code might run in less clock cycles. Nowadays processors are much more complicated, with pipelining, prefetch queue, caching, superscalar design etc, so optimizations can be quite.. daring. :)