This is the mail archive of the
mailing list for the GCC project.
Re: Patch to add __builtin_printf("string\n") -> puts("string")
- To: gdr at codesourcery dot com
- Subject: Re: Patch to add __builtin_printf("string\n") -> puts("string")
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Fri, 22 Sep 2000 09:45:48 -0400 (EDT)
- Cc: gcc-patches at gcc dot gnu dot org, harinath at cs dot umn dot edu
> From: Gabriel Dos Reis <email@example.com>
> | In the given example, the printf call site sees a pointer variable,
> | not a string constant, so the optimization isn't performed. Its only
> | performed for cases like printf("foo\n") where the string constant is
> | explicit.
> But, what if, in the not so distant future, the front-end has
> tree-based optimization which replaces p with "foo\n" ?
First of all, let me say I welcome tree-based optimizations and look
forward to using them to enable other transformations. :-)
However since the tree-based opt you mention isn't done yet, its hard
to comment on your specific case, but I suspect it won't be a problem.
If you look again at my patch, you'll see that it goes out of its way
to copy the string and makes an entirely new STRING_CST and parameter
list when chopping off the trailing "\n" for than individual call. So
the opt wouldn't interfere should the original string be used
elsewhere. I.e. both the original string and the chopped one would
get output should they both be needed.
I suppose you could argue that the second string would waste space but
so far, in the sample code I manually checked, these duplicates don't
occur. In fact code size went down due to all the string size
reductions. So should some pathological case arise, it will be
mitigated by the many more string space reductions.
I used genattrtab.o as an example of code that makes heavy use of
printf("string\n") and I'm seeing performance gains and no errors, nor
did I see diffs in the generated insn-attrtab.c file.
In light of all this, do you still believe there is cause for concern?
> It is my opinion code optimization should come after correct
> semantics, not before.
That is not in dispute! :-) But I believe my copy approach (and
testing so far confirms) that I preserve correct semantics.
Kaveh R. Ghazi Engagement Manager / Project Services
firstname.lastname@example.org Qwest Internet Solutions