Which is faster : if (bool) or if(int)?

Question

Which value is better to use? Boolean true or Integer 1?

The above topic made me do some experiments with bool and int in if condition. So just out of curiosity I wrote this program:

int f(int i)  {     if ( i ) return 99;   //if(int)     else  return -99; } int g(bool b) {     if ( b ) return 99;   //if(bool)     else  return -99; } int main(){} 

g++ intbool.cpp -S generates asm code for each functions as follows:

• asm code for f(int)

  __Z1fi:    LFB0:          pushl  %ebp    LCFI0:           movl  %esp, %ebp    LCFI1:           cmpl  $0, 8(%ebp)           je    L2           movl  $99, %eax           jmp   L3    L2:           movl  $-99, %eax    L3:           leave    LCFI2:           ret 

• asm code for g(bool)

  __Z1gb:    LFB1:           pushl %ebp    LCFI3:           movl  %esp, %ebp    LCFI4:           subl  $4, %esp    LCFI5:           movl  8(%ebp), %eax           movb  %al, -4(%ebp)           cmpb  $0, -4(%ebp)           je    L5           movl  $99, %eax           jmp   L6    L5:           movl  $-99, %eax    L6:           leave    LCFI6:           ret 

Surprisingly, g(bool) generates more asm instructions! Does it mean that if(bool) is little slower than if(int)? I used to think bool is especially designed to be used in conditional statement such as if, so I was expecting g(bool) to generate less asm instructions, thereby making g(bool) more efficient and fast.

EDIT:

I'm not using any optimization flag as of now. But even absence of it, why does it generate more asm for g(bool) is a question for which I'm looking for a reasonable answer. I should also tell you that -O2 optimization flag generates exactly same asm. But that isn't the question. The question is what I've asked.

---

Answer 1

Makes sense to me. Your compiler apparently defines a bool as an 8-bit value, and your system ABI requires it to "promote" small (< 32-bit) integer arguments to 32-bit when pushing them onto the call stack. So to compare a bool, the compiler generates code to isolate the least significant byte of the 32-bit argument that g receives, and compares it with cmpb. In the first example, the int argument uses the full 32 bits that were pushed onto the stack, so it simply compares against the whole thing with cmpl.

Answer 2

Compiling with -03 gives the following for me:

f:

    pushl   %ebp     movl    %esp, %ebp     cmpl    $1, 8(%ebp)     popl    %ebp     sbbl    %eax, %eax     andb    $58, %al     addl    $99, %eax     ret 

g:

    pushl   %ebp     movl    %esp, %ebp     cmpb    $1, 8(%ebp)     popl    %ebp     sbbl    %eax, %eax     andb    $58, %al     addl    $99, %eax     ret 

.. so it compiles to essentially the same code, except for cmpl vs cmpb. This means that the difference, if there is any, doesn't matter. Judging by unoptimized code is not fair.

---

Edit to clarify my point. Unoptimized code is for simple debugging, not for speed. Comparing the speed of unoptimized code is senseless.