Has there ever been a C compiler where using ++i was faster than i++?

Question

Please take a look at this post: Is there a performance difference between i++ and ++i in C?

There are two essential statements in the answer:

1. Modern compiler produce the same machine code no matter whether i++ or ++i is used.
2. On old compilers i++ might be slower because it has to remember the old value.

I personally verified statement 1 and can confirm it.

But I have a problem with statement 2 as I cannot find any example where the old value of i is used and i++ can be replaced by ++i. To make it clear here is an example:

printf("the value of i is %i\n", i++);

I cannot simply replace i++ with ++i as it has a different return value. I can only imagine examples where the return value is not used. For example:

while (i < 10)
{
  i++;
}

I now can replace i++ with ++i. But does this make it faster? Did any compiler ever save the old value of a variable which is then never used (the old value)?

Can anyone provide a code example and the disassembly of the compilation where indeed using ++i instead of i++ makes it faster? Using an old compiler of course.

I hope you understand this is a historical retro question as probably all compilers optimize this for decades.

Answer 1

I would answer "yes" on the basis that C compilers are (or at least appear) simple enough that plenty of amateurs and students will have a go at writing one, and at least some of them will screw this up. Proving this requires naming a concrete example, but since this would be a rather tedious and unrewarding research project involving seeking-out terrible compilers and getting them up and running and inspecting their output, I'm going to pass on that.

The quality of compilers improved substantially roughly 30 years ago due to a couple of factors: The first is fairly boring in that that computers just got faster and had more memory so could perform optimisations which were prohibitively-expensive or impossible on earlier machines. The second is that there were major advances in computer science such as SSA Form which enabled much more rigorous and exhaustive analysis of code flow which previously tended to be done in a somewhat ad hoc manner. In particular, it would be noticed that the value returned by i++/++i is never used, and so the code producing the value (but not the code performing the increment, unless it turned out that i was also unused) would be deleted. So that's why "Modern compiler produce the same machine code no matter whether i++ or ++i is used".

(If your compiler textbook is from the 1990s or earlier, it's time to retire it and get the current edition.)

Very early and primitive compilers would pretty much emit precanned assembler fragments while parsing, and rely on a peephole optimiser to eliminate the more obvious redundant instructions. i++ might for example result in an instruction to copy i into the register designated for holding the result of expression evaluation, and another which increments i. The peephole optimiser may well notice that the result is immediately overwritten by the next bit of code and thus clearly unused and the instruction can be eliminated. Or it might not. The only good thing to say about this design of compiler is that it can work in a single pass without loading the whole program in memory, and so run on appallingly-small machines. Original ANSI C syntax is that way pretty much so that this sort of compiler can be used on it.

Answer 2

A bit of tinkering in turns up a counter-example to the first statement.

The below code in produces generates the below assembly when compiled with current GCC for x64 (https://godbolt.org/z/9naWMrjf3) without optimization enabled:

_Atomic int v;
void pre(void) { ++v; }
void post(void) { v++; }


pre:
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-8], 1
        mov     eax, DWORD PTR [rbp-8]
        mov     edx, eax
        mov     eax, edx
        lock xadd       DWORD PTR v[rip], eax
        add     eax, edx
        mov     DWORD PTR [rbp-4], eax
        nop
        pop     rbp
        ret
post:
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-8], 1
        mov     eax, DWORD PTR [rbp-8]
        lock xadd       DWORD PTR v[rip], eax
        mov     DWORD PTR [rbp-4], eax
        nop
        pop     rbp
        ret

The postfix version uses the initial value yielded as the result of an x86 exchange-add atomic instruction without re-computing the result.

My best guess is that some version of some legacy compiler with optimization disabled would make the assumption that the result of a post-increment may be used and generate different. However, I have no counter-example to back this up.

Answer 3

I now can replace i++ with ++i. But does this make it faster?

No, as in the form used both are to be reduced as a simple increment (sequence). There are no other operations done with either old or new value.

The situation may be different when used in an expression like a[i++] = j[i] vs. a[++i] = j[i]. Especially on CPUs that only implement one of those addressing modes native.

Can anyone provide a code example and the disassembly of the compilation where indeed using ++i instead of i++ makes it faster?

This still would only resolve do differences in CPU architecture, wouldn't it?

I hope you understand this is a historical retro question as probably all compilers optimize this for decades.

Not really, as this is a generic language question, not really a historic one unless you can tie it to a certain implementation or compiler strategy of a certain time. Just asking a qestion in 'has there been form' doesn't make it a historic one.

Answer 4

Yes, but these are not semantically equivalent, of course, so we're not comparing apples to apples as it were.

The HP/1000 is effectively an accumulator machine; its C compiler in the early 1980's would generate code sequences such as:

• i++: load i, add 1, store i, subtract 1.

Whereas the other

• ++i: load i, add 1, store i, then use as is

Delaying the increment for after the expression's use would most certainly mitigate the extra subtraction, however, that takes some compiler work, and, a new load/add/store sequence would generally be needed, so not necessarily even getting the benefit, being a wash unless the original i was still in one of the two accumulators.

Answer 5

Did any compiler ever save the old value of a variable which is then never used (the old value)?

For the C code

int i;
foo() { ++i; }
bar() { i++; }

the PDP-11 Unix V6 C compiler produces:

.globl  _i
.comm   _i,2
.globl  _foo
.text
_foo:
~~foo:
jsr     r5,csv
inc     _i
L1:jmp  cret
.globl  _bar
.text
_bar:
~~bar:
jsr     r5,csv
inc     _i
L2:jmp  cret
.globl
.data

The code is identical.

Answer 6

This was definitely the case for the Consulair C compiler for MacOS that I used for a few years in the mid 1980s.

The 68000 processor has post-increment instructions, allowing you to calculate *p++ with a single instruction (read from pointer p with post increment), so reading *p++ should have been faster than reading *++p. However, the compiler wasn't smart enough for that. It translated *p++ literally into (p += 1, *(p-1)), producing one add instruction, plus one memory access with a non-zero offset to access p[-1], while *++p was an add instruction, plus one memory access with 0 offset, which was shorter and faster.

All made more annoying by the fact that *p++ should have been faster.

Answer 7

It depends on the way the optimizer works.

Basically, everything that uses SSA form internally will generate the same code, because both ++i and i++ generate a new register for the incremented value and subsequent code will use that register to refer to i until it is overwritten again, and the only difference is that when the value of the expression is used, it refers to the "new" register in one case and to the "old" register in the other -- so when the value is unused, there is no place where the register number is inserted, so there is no code that can be different.

The only compilers that could generate different code are those that do not use SSA as an intermediate form. Those will likely be bootstrapping compilers, where performance of generated code is largely irrelevant.

Answer 8

I used to be a compiler writer, and had the opportunity to test this code on many CPUs, operating systems, and compilers. The only compiler I found that didn't optimize the i++ case (in fact, the compiler that brought this to my attention professionally) was the Software Toolworks C80 compiler by Walt Bilofsky. That compiler was for Intel 8080 CP/M systems. It's safe to say that any compiler which does not include this optimization is not one meant for general use

Is there a performance difference between i++ and ++i in C?

---

As commented, TCC is another example

TCC performs only few optimizations, the code is generated in a single pass and every C statement is compiled on its own. It seems that the compiler is almost as simple as possible so it does not store any state during the compilation if it is not necessary.

Why is the ecx register used during an inc instruction

But since TCC is "relatively new" we can consider its dead ancestor OTCC retro

Answer 9

The knee jerk to go to ++i might be there just to avoid confusion. For any given person one of those is going to feel like it returns the correct value and the other like it doesn't. A mathematical operator that doesn't apply before assignment is exceptional in C, so I could see trying to avoid the i++ case. It's like trying to intentionally put the constant on the left side of ==, it reduces the chance of a difficult-to-see mistake. In other words it may increase programmer performance.

Answer 10

For the examples that you have shown you are correct that there is no difference in speed if i is an integer, char, or other basic type, and the result is not being used. If you use the result on the same line then the produced code will be different: int a = ++i produces different code than int a = i++.

However

A better question is, what if i is not an int, char, or other basic type? But has a prefix/postfix incrementor defined? What does the compiler do then? It would be nice if the complier was smart enough to swap out the post-fix operation with the prefix if the use case is identical to what you showed... Sadly, the compiler makers are smart enough to know that it is possible for the post-fix incrementor to do something different then the pre-fix incrementor for user defined types. So it is not allowed to swap them out even though the i++ might include an unneeded, and computationally wasteful copy.

My answer is For basic types, the pre/postfix does not matter. But if you use custom classes with overloaded pre/postfix operators then prefix will be faster then postfix, so it is a good habit to use ++i instead of i++. I think optimization levels might make a difference, I believe that o4 will intelligently change i++ to ++i, but I am not sure at this moment.

Answer 11

I had an interview phone call with Oracle/London. While discussing, I asked the interviewer "what is the difference between ++i and i++" ? A month later, he sent me an email. Yes, one of them needs to store the value (in a register, stack, etc). So, it depends on processor architecture, compiler implementation and usage. If we have a tiny processor, with few registers and resources and want use that in a loop for millions of times ... better think about it. I do not see that kind of requirements now.