This is the mail archive of the
mailing list for the GCC project.
Re: Patch to add __builtin_printf
- To: tv at pobox dot com
- Subject: Re: Patch to add __builtin_printf
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Tue, 19 Sep 2000 14:00:21 -0400 (EDT)
- Cc: gcc-patches at gcc dot gnu dot org
> From: Todd Vierling <firstname.lastname@example.org>
> On Tue, 19 Sep 2000, Kaveh R. Ghazi wrote:
> : This patch adds __builtin_printf. It uses the same mechanism for
> : obtaining the FUNCTION_DECL for the replacements as does builtin
> : fputs, namely declare stub replacement builtins and cache the result.
> Would it be possible to do similar replacements for fprintf?
> fprintf(file, "%s", foo) -> fputs(foo, file) [*]
> fprintf(file, "%c", foo) -> fputc(foo, file) [**]
> fprintf(file, "c") -> fputc('c', file) [**]
Yes, these are in the works. Though there are some problems I need to
solve WRT declaring the builtin with a FILE* and "..." that I'll
detail in a future message. But first I'm going to add another printf
> If desired, an additional optimization for
> "%s\n" could consist of a builtin_fputs followed by a builtin_fputc,
> likely still faster than the fprintf.
> [**] Though not as fast as the typical macro putc() due to the function call
> overhead, fputc() is quicker than fprintf() in these cases, and the
> function call was there to begin with anyway. If a builtin fputc()
> takes over at this point, that's an added bonus.
I've designed ways to trap the putc macro as an inline function and
issue it as a replacement for fputc, but the resulting code size
increase has been significant relative to the speed increase. I might
only provide that one as a special -f option or perhaps at -O3, if at
all. The same issue arises for fprintf("%s\n") -> fputs+fputc, though
not as pronounced.
Kaveh R. Ghazi Engagement Manager / Project Services
email@example.com Qwest Internet Solutions