This is the mail archive of the
mailing list for the GCC project.
Re: Patch for builtin fputs (first stdio opt ready for install)
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: Patch for builtin fputs (first stdio opt ready for install)
- From: Jason Merrill <jason at redhat dot com>
- Date: 05 Sep 2000 14:18:19 -0700
- Cc: gcc-patches at gcc dot gnu dot org
- References: <200009052038.QAA28398@caip.rutgers.edu>
>>>>> Kaveh R Ghazi <firstname.lastname@example.org> writes:
>> From: Jason Merrill <email@example.com>
>> Date: 08 Jul 2000 22:18:38 -0700
>> Sorry this has sat for so long.
>> Looking at it again, I don't see why we need the get_decl stuff at
>> all. Why not just declare a __builtin_fputc and use that, rather than
>> trying to look it up?
> I have some time to return to the stdio opts and I wanted to break the
> log-jam and get the first one installed. So I'm returning to your
> last message on the issue which raised the above question. This
> thread can be reviewed at the following URLS:
> The original patch I submitted implemented a __builtin_fputs which
> calls fputc if the string is one character long. I provided a way for
> various front ends to supply a hook to the generic builtin code in
> order to get a language dependent tree containing the global
> identifier for fputc. I need this in order to manually build up a
> CALL_EXPR of an ADDR_EXPR of a FUNCTION_DECL which I can then hand off
> to expand_expr (expand_call). This is what the get_decl mechanism
> does. Each front end sets a function pointer to the function which
> returns the value I need.
> When you suggest declaring a __builtin_fputc, I don't see how that
> avoids the need for the hook since we still need to somehow lookup the
> global identifier and extract the FUNCTION_DECL and create a CALL_EXPR
> that we can expand (if I understand things correctly, which I probably
You could save a pointer to the _DECL for __builtin_fputc in
Or you could just use emit_library_call and dispense with the _DECL
entirely; that's probably the easiest solution.
> Future optimizations will require expanding into other builtins,
> regular libc calls and inline functions we'll declare behind the
> scenes. This is why I felt the get_decl mechanism was useful as a
> generic way to get info out of language dependent tree structures.
> E.g. there will actually be a builtin_fputc eventually, but I wanted
> to submit one optimization at a time to avoid overloading the
> reviewer. This however won't change the need for get_decl.
> If I'm heading in the wrong direction, please help me understand a
> better approach. If you would please take another look at the patch
> in question at the first URL above, I'd very much appreciate it.