This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch for builtin fputs (first stdio opt ready for install)


>>>>> Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

 >> From: Jason Merrill <jason@redhat.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:

 > http://gcc.gnu.org/ml/gcc-patches/2000-04/msg00833.html
 > http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00284.html

 > 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
 > don't...)

You could save a pointer to the _DECL for __builtin_fputc in
c_common_nodes_and_builtins.

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.

Jason

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]