为什么 GCC 不优化对 printf 的调用？

Question

#include <stdio.h>
int main(void) { 
    int i;
    scanf("%d", &i);
    if(i != 30) { return(0); } 
    printf("i is equal to %d\n", i);
}

It appears that the resulting string will always be "i is equal to 30", so, why doesn't GCC optimize this call to printf with a call to puts() , or write() , for example?

(Just checked the generated assembly, with gcc -O3 (version 5.3.1), or on the Godbolt Compiler Explorer )

Answer 1

First of all, the problem is not the if ; as you saw, gcc sees through the if and manages to pass 30 straight to printf .

Now, gcc does have some logic to handle special cases of printf (in particular, it does optimize printf("something\\n") and even printf("%s\\n", "something") to puts("something") ), but it is extremely specific and doesn't go much further; printf("Hello %s\\n", "world") , for example, is left as-is. Even worse, any of the variants above without a trailing newline are left untouched, even if they could be transformed to fputs("something", stdout) .

I imagine that this comes down to two main problems:

• the two cases above are extremely easy patterns to implement and happen quite frequently, but for the rest probably it's rarely worth the effort; if the string is constant and the performance is important, the programmer can take care of it easily - actually, if the performance of printf is critical he shouldn't be relying on this kind of optimization, which may break at the slightest change of format string.

  If you ask me, even just the puts optimizations above are already "going for the style points": you are not really going to gain serious performance in anything but artificial test cases.

• When you start to go outside the realm of %s\\n , printf is a minefield, because it has a strong dependency on the runtime environment; in particular, many printf specifiers are (unfortunately) affected by the locale, plus there are a host of implementation-specific quirks and specifiers (and gcc can work with printf from glibc, musl, mingw/msvcrt, ... - and at compile time you cannot invoke the target C runtime - think when you are cross-compiling).

  I agree that this simple %d case is probably safe, but I can see why they probably decided to avoid being overly smart and only perform the dumbest and safest optimizations here.

---

For the curious reader, here is where this optimization is actually implemented; as you can see, the function matches a restricted number of very simple cases (and GIMPLE aside, hasn't changed a lot since this nice article outlining them was written). Incidentally, the source actually explains why they couldn't implement the fputs variant for the non-newline case (there's no easy way to reference the stdout global at that compilation stage).

Answer 2

Modern compilers are quite clever, but not clever enough to foresee the output using logic. In this case, it's quite simple for human programmers to optimise this code, but this task is too hard for machines. In fact, predicting the output of a program without running it is impossible for programs (gcc for example). For proof, see halting problem .

Anyway, you don't expect all programs without inputs to be optimised to several puts() statements, so it's perfectly reasonable for GCC not to optimise this code containing one scanf() statement.

---

However, this does not mean compilers cannot or should not be optimised to generate more optimised executive files. Although it's impossible to predict the result all programs, it's perfectly possible and hopeful to improve many of them.

Answer 3

Not sure if this is a convincing answer, but I would expect that compilers shouldn't optimize printf("%d\\n", 10) case to puts("10") .

Why? Because this case could be more complicated than you think. Here are some of the problems I can think of at the moment:

1. Convert binary numbers to ASCII increases size of string literal , and thus overall code size. Although this is irrelevant to small numbers, but if it's printf("some number: %d", 10000) ---- 5 digits or more (assuming int is 32-bit), the string size increased will beat the size saved for the integer, and some people could consider this a drawback. Yes, with the conversion I saved a "push to stack" instruction, but how many bytes the instruction is and how many would be saved is architecture-specific. It's non-trivial for a compiler to say if it's worth it.

2. Padding , if used in formats, can also increase size of expanded string literal. Example: printf("some number: %10d", 100)

3. Sometimes I the developer would share a format string among printf calls, for code size reasons:

    printf("%-8s: %4d\\n", "foo", 100); printf("%-8s: %4d\\n", "bar", 500); printf("%-8s: %4d\\n", "baz", 1000); printf("%-8s: %4d\\n", "something", 10000);

   Converting them to different string literals might lose the size advantage.

4. For %f , %e , and %g , there is a problem that decimal point "." is locale-dependent. Hence the compiler cannot expand it to string constant for you. Although we are only discussing about %d I mention this here for completeness.