Nathan J. Williams wrote:

> A library call is defined to have a particular effect.
> 
> Any code the compiler generates with this effect is valid.
> 
> Your intuition that this must involve a "function call" in the
> conventional sense has no backing in the standard.

Any optimization that specializes a function in some way will not be 
possible if the action must involve a function call. Inlining is the 
most well-known, but here are some others:

polyvariance: inline a function at _some_ call-sites based on if the 
inlining yields a gain in performance and the code does not explode (the 
basic example is a function with a big switch {} block where the case is 
known at the call-site. Conventional inlining would not inline the 
switch {} because it is too big, but at a certain call-site everything 
but the correct case-block can be eliminated).

generation of new functions based on substitution of constant parameters 
in the body: of dubious quality today because of caches and thrashing of 
them, but nevertheless possible.

In general you cannot expect the compiler to put function calls in the 
same place as you did. If the compiler finds a better place to split 
your program, why not let it?

I see this particular printf()/puts() rewrite as a special case of 
partial evaluation/specialization. The compiler would, with enough 
data-flow analysis and polyvariance, be able to optimize the _printf()_ 
function into the equivalent of puts(). It would require a theoretical 
compiler with binding-time analysis and possible long compile times too, 
but it is certainly possible, albeit complex beyond recognition. GCC 
instead adopted for detecting this special case and substituting. I 
cannot find any justification for not allowing it to.