This is the mail archive of the
mailing list for the GCC project.
Re: Problems with sibling calls
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 29 May 2009 17:38:23 +0100
- Subject: Re: Problems with sibling calls
- References: <4A1FB71D.email@example.com> <4A1FF28D.firstname.lastname@example.org> <4A2017A0.email@example.com>
Georg-Johann Lay wrote:
> But this will only (or is intended to) track information for the caller,
> not information needed for the callee that was gathered in the mentioned
> hooks. It can be used, of course, to exchange data between hooks
> provided with CUMULATIVE_ARGS and hooks that aren't, but it would still
> make implications on how the hooks get called in calls.c:expand_call().
You decide whether to allow sibcalls on a per-caller basis generally. All
the information needed to know how the arguments will be passed is available
at the call site, and your backend knows how arguments are passed, so it can
decide then whether the callee is also suitable or not. It shouldn't be a
significant overhead even if you have to evaluate the suitability of the same
callee multiple times in independent callers.