GCC doesn't make use of inc

Question

The GCC compiler

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

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;
}

Instead, it generates an add instruction:

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?

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?

Have you tried `gcc -Os` ? The issue is, that variants of `add` are probably faster on post +386 and `inc` will be internally translated to `add` anyway. — Aki Suihkonen, Nov 10 '13 at 13:19
See this answer: http://stackoverflow.com/questions/5993326/relative-performance-of-x86-inc-vs-add-instruction — thebjorn, Nov 10 '13 at 13:23
Modern processors don't execute machine code. They have a risc-like execution engine that execute multiple micro-ops concurrently. A read-modify-write instruction like INC gums-up superscalar execution. An older architecture like Pentium 4 executes ADD in 0.25 cycles, INC in 0.5 cycles. Newer ones do both at 0.33 cycles so it just doesn't matter. Check out the Agner Fog manuals. — Hans Passant, Nov 10 '13 at 13:36
Yes, but a processor option wasn't used (march/mtune/mcpu), so for all GCC knows, it might matter. — Robin Green, Nov 10 '13 at 13:50

score 12 · Accepted Answer · answered Nov 10 '13 at 13:44

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

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):

The INC and DEC instructions modify only a subset of the bits in the flag register. This creates a dependence on all previous writes of the flag register. This is especially problematic when these instructions are on the critical path because they are used to change an address for a load on which many other instructions depend. Assembly/Compiler Coding Rule 33. (M impact, H generality) INC and DEC instructions should be replaced with ADD or SUB instructions, because ADD and SUB overwrite all flags, whereas INC and DEC do not, therefore creating false dependencies on earlier instructions that set the flags.

Robin Green · Answer 2 · 2013-11-10T13:46:53.733

It ~~may~~ does depend on the exact optimization settings you are using (or not using). GCC can either be told to optimise for time or space (although optimising for space can sometimes be an effective way to optimise for execution time!)

Just because an instruction is available for a specialist task, doesn't mean it's necessarily the most efficient one to use.

Some of the old x86 instructions are actually implemented in microcode, not in hardware any more, because they are rarely used and aren't worth implementing in hardware. But this can make them slower. I don't know whether inc is such an instruction.

Also, if you don't tell GCC which x86 processor model you are going to be running the code on, it will have to guess at something generic.

GCC doesn't make use of inc

2 Answers2

Linked