[PATCH] printf optimization

Jakub Jelinek jakub@redhat.com
Tue Jun 4 07:04:00 GMT 2002


On Tue, Jun 04, 2002 at 02:49:38PM +0100, Joseph S. Myers wrote:
> On Tue, 4 Jun 2002, Mark Dettinger wrote:
> 
> > This is a patch for GCC 3.1 that introduces a printf optimization:
> 
> If you want to do this you'll need to read and follow the GNU Coding
> Standards for formatting (and the GCC coding conventions), send in an
> assignment (and possibly an employer disclaimer), write the code so as to
> integrate with the existing printf builtin function optimization support
> (see c_expand_builtin_printf in c-common.c) rather than a whole new
> mechanism, as a patch against mainline (not 3.1), and include testcases as
> described in the GCC coding conventions.  I suggest also including
> benchmarks showing how much testcases get speeded up (noting that if all
> arguments are constant, the other optimizations already present may come
> into play) and discussing the design and implementation with Kaveh who
> implemented the previous printf optimization support.

Plus you need to weight the advantages against its disadvantages,
particularly that it goes against the constant string merging optimization.
E.g. say if there is a macro like:
#define FANCYPRINT(text) printf ("%s:%d %s\n", __FILE__, __LINE__, (text))
then currently lots of strings will be successfully merged (e.g. all "%s:%d %s\n"
strings into one, there will be just one string for each
filename and one string for each possible text printed by FANCYPRINT.
With your patch, such string merging will be very rare, as string like:
"foo.c:26 foo text\n" cannot be merged with different string like
"bar.c:78 foo text\n" etc.

	Jakub



More information about the Gcc-patches mailing list