This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH RFC: stdio optimization [take 2]
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: PATCH RFC: stdio optimization [take 2]
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 04 Jan 2000 02:42:30 -0700
- cc: gavin at cygnus dot com, egcs-patches at egcs dot cygnus dot com, mark at codesourcery dot com
- Reply-To: law at cygnus dot com
In message <199912221658.LAA26539@caip.rutgers.edu>you write:
> Now here are the shortcomings: :-(
>
> 1. It works for C and Objc, but not for C++. I don't know why, but
> C++ won't expand the inline wrapper functions. It emits them as
> extern functions (which I thought was impossible if they were declared
> as extern __inline__) and then calls them explicitely.
Hopefully one of the C++ front-end gurus can help.
> 2. IMO, there are too many wrappers in stdio-opt.h. I needed these
> to maintain the return value and signature of each function so I
> wouldn't have to jump through too many hoops to make a replacement.
> Suggestions (and instructions) for reducing the number would be great.
>
> E.g. I could elimintate those only needed for the return value if I
> could detect when the return value was not used and punt in those
> cases. But I don't know how to detect that. I could also use some
> help on how to build arglists with different argument types. E.g.
> given a constant string parameter, how do I take string[0] and
> transform it into a char/int in a function call in a language
> independent manner?
First I assume you need to detect when the return value is unused at the
tree level? If so, look and see under what conditions expand_call is called
with the IGNORE as nonzero and trace how that decision is made (probably
in expand_expr).
Presumably the string[0]->char/int transformation is also happening at the
tree level? If so, extract the relevent char out of the string and
build up a new tree constant. You might write a hunk of C code which does
something similar and look at the tree nodes that get generated.
> 3. The setup forces you to include stdio-opt.h for now. I'll
> eventually have stdio.h include stdio-opt.h automatically.
> (Suggestions for the best way to do this are welcome.)
If fixincludes provided you with a fixed copy of stdio.h, then you can
put the inclusion of stdio-opt.h at the front of the file.
Else make a wrapper which includes stdio-opt.h, then does an #include_next
stdio.h.