Question

Let’s say I have following code:

int f() {
  int foo = 0;
  int bar = 0;

  foo++;
  bar++;

  // many more repeated operations in actual code
  foo++;
  bar++;

  return foo+bar;
}

Abstracting repeated code into a separate functions, we get

static void change_locals(int *foo_p, int *bar_p) {
  *foo_p++;
  *bar_p++;
}

int f() {
  int foo = 0;
  int bar = 0;

  change_locals(&foo, &bar);
  change_locals(&foo, &bar);

  return foo+bar;
}

I’d expect the compiler to inline the change_locals function, and optimize things like *(&foo)++ in the resulting code to foo++.

If I remember correctly, taking address of a local variable usually prevents some optimizations (e.g. it can’t be stored in registers), but does this apply when no pointer arithmetic is done on the address and it doesn’t escape from the function? With a larger change_locals, would it make a difference if it was declared inline (__inline in MSVC)?

I am particularly interested in behavior of GCC and MSVC compilers.

Answer 1

inline (and all its cousins _inline, __inline…) are ignored by gcc. It might inline anything it decides is an advantage, except at lower optimization levels.

The code procedure by gcc -O3 for x86 is:

        .text
        .p2align 4,,15
.globl f
        .type   f, @function
f:
        pushl   %ebp
        xorl    %eax, %eax
        movl    %esp, %ebp
        popl    %ebp
        ret
        .ident  "GCC: (GNU) 4.4.4 20100630 (Red Hat 4.4.4-10)"

It returns zero because *ptr++ doesn’t do what you think. Correcting the increments to:

    (*foo_p)++;
    (*bar_p)++;

results in

        .text
        .p2align 4,,15
.globl f
        .type   f, @function
f:
        pushl   %ebp
        movl    $4, %eax
        movl    %esp, %ebp
        popl    %ebp
        ret

So it directly returns 4. Not only did it inline them, but it optimized the calculations away.

Vc++ from vs 2005 provides similar code, but it also created unreachable code for change_locals(). I used the command line

/O2 /FD /EHsc /MD /FA /c /TP