Re: [PATCH] Move printf and fprintf builtins to middle-end.

[Roger Sayle <roger at eyesopen dot com>]

Hi Kaveh and Jakub,
> All this means is that after we write the optimization, we have to
> look at real-life code and see whether on average we have a net win or
> not.  And whether we can mitigate the losing cases through some
> heuristics.

Might I also make the potentially politically incorrect comment that
it shouldn't automatically be a crime to increase executable size.

For the optimization examples under discussion, we have an expansion
in memory usage for error messages that are typically rarely, often
never accessed.  Placed in a read-only segment, they may never even
be paged in from disk on some operating systems.  However, for the
types of printfs/fprintfs/sprintfs in frequently executed code, there
may be a real performance advantage.  I appreciate GCC also needs to
support embedded systems, which is why we also have -Os, which should
naturally disable this transformation.


To summarise, I think that final code size shouldn't be the only metric
by which we evaluate whether to apply this optimization or not.  For
example, if there's a significant drop in GCC bootstrap time, I still
think that could take priority over increase in cc1 size.  Basically,
this optimization should be reviewed under the same guidelines that
we use for loop unrolling or inlining heuristics.

"Code bloat, for lack of a better word, is good", but I appreciate
that not everyone may be as forward thinking :>

Roger
--