为什么GCC没有将'printf'优化为'put'？

Question

Here is my test code:

#include<stdio.h>

static inline void foo(int a){
    printf("%x\n", a);  
}

int main(void){
    foo(0x1234);    
    return 0;
}

I thought GCC should realize that a is a literal integer, and optimize to code like this:

puts("1234");

But I got the following assembly code:

│0x8048341 <main+17>     push   $0x1234                                        
│0x8048346 <main+22>     push   $0x80484e0                                  
│0x804834b <main+27>     push   $0x1                                        
│0x804834d <main+29>     call   0x8048310 <__printf_chk@plt> 

There exists a lot of such code in my project, because I always believed that GCC would optimize for me, and even in some context where could simply use 'write()', I insisted using printf , because I thought I would gain benefit from its buffer mechanism.

Now I feel regret, for the overhead of paring a format string will kill any gain I have. These codes in my project are quite low-level, and they might cause the performance bottleneck.

Answer 1

These codes in my project are quite low-level, and they might cause the performance bottleneck.

First off, I can assuage your fears that this is not possible. The overhead of console I/O is tremendous (relatively speaking), so that will always be the bottleneck in your code, no matter what means you use to do it.

I thought gcc should realize that a is a literal integer, and optimize to code like this:

 puts("1234"); 

Clearly it doesn't. GCC (and Clang) does perform an optimization where printf("...\\n"); is transformed into puts("..."); , as you can see here , but this only happens when you use string literals with printf . The optimizer doesn't (currently) peek into the format string, parse it, and optimize around it. You called printf , so you get printf .

Compiler optimizations aren't guaranteed , so you shouldn't write code that relies on them without first verifying that the desired optimizations are in fact being applied under all circumstances in which you are interested (including code variations, compiler versions, target platforms, etc.).

If you'd like to suggest this as a possible improvement for the GCC optimizer, you can suggest an enhancement on their Bugzilla . But don't hold your breath on it being implemented any time soon. The logic required to implement this type of optimization is not really worth the effort, considering the real-world performance improvements that could be expected are minimal at best (see above).

In the meantime, if you absolutely require this optimization with minimal changes to your code, then you can use some macro hackery :

#define STRINGIFY_INTERNAL(x)  #x
#define STRINGIFY(x)           STRINGIFY_INTERNAL(x)

#define foo(a)                 puts(STRINGIFY(a))

This does produce the desired output:

.LC0:
        .string "0x1234"
MyFunction:
        sub     esp, 24
        push    OFFSET FLAT:.LC0
        call    puts
        xor     eax, eax
        add     esp, 28
        ret

Answer 2

A conforming library implementation could include functions beyond those defined by the Standard, which would change the way standard functions behave. For example, a library might include a __select_alternate_digits function that, when invoked, would cause succeeding calls to printf to display numbers using something other than the normal digits.

With such a library, given the code:

#include <stdio.h> // Could legitimately include functions that aren't
                  // defined by the Standard, but which start with __.

int main(void)
{
  __select_alternate_digits("⁰¹²³⁴⁵⁶⁷⁸⁹");
  printf("%d",123);
  __select_alternate_digits(0); // Reset to default set      
}

the call to __select_alternate_digits might cause the above program to output "¹²³" rather than "123". If the compiler bundled its own printf function, it could know that its behavior wasn't going to be affected by any other function calls. If it's using an outside library, however, then unless the program is completely free of any calls to functions the compiler knows nothing about, a quality compiler should assume those functions might have effects the compiler can't predict.