本文介绍了GCC不使用INC的的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

限时删除!!

GCC编译器

$ gcc --version
gcc (GCC) 4.8.2
...

不产生 INC 汇编指令,它实际上可能是有用的,就像这个C程序:

doesn't generate an inc assembly instruction, where it could actually be useful, like in this C program:

int main(int argc, char **argv)
{
    int sum = 0;
    int i;
    for(i = 0; i < 1000000000L; i++)                     <---- that "i++"
        sum += i;
    return sum;
}

相反,它生成一个添加指令:

0000000000000000 <main>:
   0:   31 d2                   xor    %edx,%edx
   2:   31 c0                   xor    %eax,%eax
   4:   0f 1f 40 00             nopl   0x0(%rax)
   8:   01 d0                   add    %edx,%eax
   a:   83 c2 01                add    $0x1,%edx         <---- HERE
   d:   81 fa 00 ca 9a 3b       cmp    $0x3b9aca00,%edx
  13:   75 f3                   jne    8 <main+0x8>
  15:   f3 c3                   repz retq

它为什么要这样做呢?

Why does it do this?

修改:我用的gcc -O2 编译此。 的gcc -Os 确实产生一个 INC 指令。没有使用 INC 多空间优化的速度优化?

EDIT: I used gcc -O2 to compile this. gcc -Os does indeed generate an inc instruction. Isn't using inc more a speed optimization than a space optimization?

推荐答案

-march =&LT试试吧,你的机器&GT; 。其结果可能是不同的。

Try it with -march=<your machine>. The result may be different.

不过,请注意,加$ 1%章不一定是一个糟糕的选择。虽然 INC 有较小的编码,这是有吸引力的,他们从事实,他们只是部分更新标志受苦,导致假依赖性问题。英特尔优化手册包含此评论(我的重点):

However, note that add $1, %reg is not necessarily a poor choice. Although inc and dec have smaller encodings, which is attractive, they suffer from the fact that they only partially update flags, leading to false dependency problems. The Intel optimisation manual contains this comment (my emphasis):

INC和DEC的指令修改仅在标志寄存器中的位的子集。这个
  创建该标志寄存器的所有previous写的依赖。这是特别
  问题当这些指令的关键路径上,因为它们是用来
  对许多其他说明取决于负载更改地址。
  大会/编译器编码规则33.(M影响,H通用)的 INC和DEC
  说明应与ADD或SUB指令
的被替换,因为ADD和
  SUB覆盖所有的标志,而INC和DEC不这样做,因此创建虚假
  上设置的标志说明前面的依赖。

这篇关于GCC不使用INC的的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

1403页,肝出来的..

09-06 08:45