Re: patch to suggest putc/fputs over printf("string") or printf("\n")

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 >  
 >   In message <199901120410.XAA12199@caip.rutgers.edu>you write:
 >   >  > From: Jeffrey A Law <law@hurl.cygnus.com>
 >   >  > 
 >   >  > Actually, I'd consider a patch which conditionally converted them for
 >   >  > the user.  We've kicked that idea around quite a bit inside Cygnus, but
 >   >  > never got excited enough to implement it.  See also:
 >   >  > 
 >   >  > http://www.nullstone.com/htmls/category/printf.htm
 >   > 
 >   > 
 >   > 
 >   >     I thought a bit about how/when to optimize printf.  Here is the
 >   > algorithm/pseudo-code I came up with.
 >   > 
 >   > WARNING: its very "pseudo" but should be readable.  :-)
 > 
 > You can't find sequential calls at the tree level, which is probably where
 > this optimization belongs.


	Nuts.  I guess this means we can't do a combine_put_calls phase,
but we can still do a reduce_printfs.

	Can we _split_ instructions at the tree level?  That would allow
us to do a split_printfs phase eventually. 


 > Something else I just thought of -- how to deal with systems where stdout
 > is a macro, not a variable?  Hmm, maybe we do have to do something earlier
 > in the compiler....
 > jeff


	I suppose we need to know the stdout expansion for changing
printf() -> fputs(, stdout) and also for fprintf(stdout, "%s\n",) -> puts(). 

	Can we stringify the stdout macro in the gcc source to get this?
Oh yeah, stringifying a macro doesn't work in traditional C.  Grr.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.