Re: PATCH for sibcalls on i386

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

On 23-Sep-2002, Zack Weinberg <zack@codesourcery.com> wrote:
> On Mon, Sep 23, 2002 at 08:03:20PM +1000, Fergus Henderson wrote:
> >
> > P.S.  If you are concerned about not changing the target machine interface,
> > then another way of handling it would be to add a new target macro
> > CALL_OK_FOR_SIBCALL(exp) which would be used for indirect calls.
> > That way the FUNCTION_OK_FOR_SIBCALL macro could remain unchanged,
> > and the existing non-x86 targets could remain unchanged, you'd just
> > need to add a default definition for it, and a definition for x86.
> > 
> > In fact thinking about it a bit more, this does seem like a better approach.
> 
> I'm not convinced.  Look at the code Andreas wrote for
> i386_function_ok_for_sibcall: 
...
> The conditionals are practically identical.
> If we had separate CALL_OK_FOR_SIBCALL and FUNCTION_OK_FOR_SIBCALL
> hooks, that would force duplication of most of this logic.

Not really.

	#define CALL_OK_FOR_SIBCALL(exp) \
		i386_ok_for_sibcall(NULL, TREE_TYPE (exp))

	#define FUNCTION_OK_FOR_SIBCALL(fndecl) \
		i386_ok_for_sibcall(fndecl, TREE_TYPE (TREE_TYPE (fndecl)))

	...

	int
	ix86_ok_for_sibcall(fndecl, return_type)
	     ...
	{
	  ...
	}

The drawback is that the interface is a little more complicated.
The advantage is that the interface remains stable -- we're only
adding new target macros, not changing the interface of existing ones.

As a front-end maintainer, I have first-hand experience of the pain that
interface changes cause.  So I'm inclined to favour interface stability
over interface simplicity in this case.

On the other hand, if the interface is already churning, then maybe one more 
interface change isn't such a big deal ;-)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.