This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH RFC: stdio optimization


  In message <199912051440.JAA28990@caip.rutgers.edu>you write:
  > 	I've begun writing the stdio optimizations I posted about long
  > ago.  (Here is some background since its been almost a year.)
  > 
  > http://www.cygnus.com/ml/egcs-patches/1999-Jan/0141.html
  > http://www.cygnus.com/ml/egcs-patches/1999-Jan/0143.html
  > http://www.nullstone.com/htmls/category/printf.htm
  > http://www.cygnus.com/ml/egcs/1999-Jan/0652.html
  > 
  > The strategy I've used is to create new builtin functions.  The first
  > optimization I wrote is converting fputc -> putc.  I've made some
  > progress but now I'm stuck.  I managed to figure out how to replace a
  > call to another external function, but it won't work if the
  > replacement function is __inline__.  (And it must be for the
  > optimization to be of any value in this case.)
Right.  Well, something like printf -> puts might still be of value if the
string is constant.  printf is bloody expensive.  And the nice thing is you
don't need to find that FILE * argument :-)  Of course you'd need that
FILE * to do fprintf -> fputs transformations.

I'm not sure how often we'll find an fputc->putc optimization opportunity, 
but it can happen.  Note that you can't blindly turn every fputc into a
builtin -- consider if fputc is used as an argument to a function.  In fact,
that is one of the main reasons why fputc exists in the first place.


  > 1.  I had to create a builtin prototype for __builtin_fputc.  However
  > fputc uses a FILE* in the argument list which is not a builtin type
  > and I'm not sure how to define FILE so it works on all platforms.
It's probably impossible, and it seems to me that it's important to get it
correct.  We need it for the builtin function, or in the macro expansion if
we took that route.

  > I had to fake this by using a ptr_type_node.  It seems to work, but
  > please double check where I set fputc_ftype whether this is correct or
  > not.
That will probably work OK until you actually try to use it to implement
putc :-)  There's probably also issues with C++ here.


  > 2.  Is calling maybe_get_identifier and checking for 0 the right way
  > to see if a function has been defined?  (Given that we must use
  > language front-end independent features.  Right?)
Not sure.  If we find that we need a language independent way to look up
an identifier, then we'll make one.


  > 3.  How do I properly setup gcc to insert an *inline* function once
  > I've trapped the place where the original goes?
You must have already seen an implementation of the function *before* the
call site where you wish to inline it.

  > I think if we can settle these issues, this first optimization will
  > work.
My gut tells me to go after printf -> puts first since you can avoid the
FILE * issue.  It'll limit you in some ways, but you can start building
the pieces you need and still get something useful out of the optimization
while you're building the rest of the pieces.

For printf->puts conversion you'd want to verify that the string has no format
chars and ends in a newline.  You'd want to pass a modified version of the
string (no newline) to puts.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]