This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: simple calls.c cleanups (help on trees needed)
> On Fri, Mar 31, 2000 at 12:19:23PM +0200, Jan Hubicka wrote:
> > I will look at the C++ bits and make C frontend to accept that attribute too.
>
> Why? It only matters if there are exception handlers in scope.
> Which there can't be in C, because you can't define them.
OK. I just considered confusing, that we have an attribute, that works
(in C) for functoins, but not for function types. Perhaps we can disable
it for functions too, since it is useless for C at all.
>
> > OK. In the near future I would like to slowly move towards to merging
> > emit_library_call_value_1 and expand_call (at least the internal loop)
> > and make it handling sibcall then.
>
> Yep.
>
> Synthesizing an appropriate FUNCTION_DECL for the libcall
> shouldn't be that tricky...
I was thinking about that path (synthetize the expression for expand_call), and
it looks like if I use RTL_EXPR for function parameters, I will run into
problems with safe_reeval. Or do you have some better idea how to synthetize
the expression? I am not very experienced in this area. So I was thinking
about alternate approach to fill args structure in expand_call and
emit_library_call separately and then call common function to emit the
neccesary insns. mit_library_call may make all args appear to be
precalculated.
Honza
>
>
> r~