Re: PATCH RFC: stdio optimization

[Jeffrey A Law <law at cygnus dot com>]

  In message <199912131825.NAA07507@caip.rutgers.edu>you write:
  >  > From: Jeffrey A Law <law@cygnus.com>
  >  > 
  >  > I'm not sure how often we'll find an fputc->putc optimization opportunit
  > y, 
  >  > but it can happen.
  > 
  > The gcc sources have 647 calls to fputc.
Wow.  I must admit I'm rather surprised (pleasantly so since it means the
patch may be helpful for gcc itself :-)

  > There are also around 250
  > places in the sources where fprintf is called with a one character
  > constant string or with a "%c" format string.
Similarly.

  > Another 65 places where
  > fputs is called with a one character constant string.
Wow.

  >  My goal is to
  > get these one character fprintfs/fputs to transform to the expansion
  > of the putc macro like this: fprintf->builtin_fputs->builtin_fputc.
  > 
  > I'm starting with the lowest common denomenator and working my way
  > backwards.
OK.  I guess we just disagree on how to start.  It seems like you're already
moving nicely, so don't pay any attention to my ramblings about what problem
to solve first :-)


  >  > That will probably work OK until you actually try to use it to implement
  >  > putc :-)  There's probably also issues with C++ here.
  > 
  > I don't intend to implement putc, the inline container will obtain it
  > for me.
OK.


  > Perhaps C++ will have a problem, I don't know.  I'll check into that
  > once I get it working for C.
FWIW, I'm mostly concerned about the C++ compiler balking about incompatible
pointers and such as well as mangling issues.


  >     Given that I can already replace a call to one extern function
  > with another extern one, all the above should be doable.  The only
  > issue I can see is maintaining the same return value sematics.  The
  > *printf functions already match *puts in returning the number of
  > characters printed.  The trick will be with fputs->fputc and
  > sprintf->strcpy.  I may need more inline wrappers to handle these two
  > so I have control over the return value.
I suspect the return values are rarely used (though feel free to prove
me wrong again!).  If that is indeed the vast majority of the cases, then
we can probably punt the case where someone wants to look at the return
value if implementing it is non-trivial.

jeff