rs6000 sibcall test

rs6000 sibcall test

[Alan Modra]

rs6000.c:function_ok_for_sibcall tests TREE_ASM_WRITTEN, like alpha.
I can't see why, at least for powerpc64-linux.  Can someone show me
why it matters?  For starters, this test stops us doing sibcalls to
functions later in a file.

Note that the powerpc64-linux linker will do the right thing by
inserting appropriate call stubs when building shared libs, even on
the simple branch emitted by the sibcall code.  There doesn't seem
to be any linkage problem..

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: rs6000 sibcall test

[Fergus Henderson]

On 06-Sep-2002, Alan Modra <amodra@bigpond.net.au> wrote:
> rs6000.c:function_ok_for_sibcall tests TREE_ASM_WRITTEN, like alpha.
> I can't see why, at least for powerpc64-linux.  Can someone show me
> why it matters?

Perhaps because of the same kind of issue that prevents sibcalls
with -fpic on x86?  On rs6000 with the AIX ABI, all code is
position-independent, so maybe there is the same issue.

But that's for the AIX ABI.  Maybe it's not appropriate for Linux.

(I'm just guessing here!)

-- 
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.

Re: rs6000 sibcall test

[Alan Modra]

Hi Fergus,

On Fri, Sep 06, 2002 at 11:00:44PM +1000, Fergus Henderson wrote:
> On 06-Sep-2002, Alan Modra <amodra@bigpond.net.au> wrote:
> > rs6000.c:function_ok_for_sibcall tests TREE_ASM_WRITTEN, like alpha.
> > I can't see why, at least for powerpc64-linux.  Can someone show me
> > why it matters?
> 
> Perhaps because of the same kind of issue that prevents sibcalls
> with -fpic on x86?  On rs6000 with the AIX ABI, all code is
> position-independent, so maybe there is the same issue.

No we don't have the problem pointed out by Jakub in
http://gcc.gnu.org/ml/gcc/2002-09/msg00210.html.  The TOC pointer,
which we use to access the plt, is restored by the caller.  Taking
Jakub's example, we'd have

in libfoo.so
.foo:
 create stack frame, and save link reg
.
.
 branch and link to bar call stub
 restore toc pointer
.
 rest of foo code
 restore link reg, pop stack frame
 branch to link reg

in libbar.so
.baz
 set return reg to 23
 branch to link reg

.bar
 branch to baz

The call stub, actually inserted by the linker, save the toc pointer
on the stack, set up the toc pointer for the called function, then
jump to the function entry point.

Oh, wait a minute.  That branch to baz is actually a branch to baz
call stub because we need to allow baz to be overridden.  Heh, that
will save the toc pointer again, overwriting the same stack frame
location used by foo.  So I've answered my own question.  Or at
least found out another linker requirement to make this work.  You
see, I think we can make the linker use a call stub that _doesn't_
save the toc register in this particular case.

> But that's for the AIX ABI.  Maybe it's not appropriate for Linux.

64 bit powerpc code on linux uses the AIX ABI.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: rs6000 sibcall test

[Alan Modra]

On Fri, Sep 06, 2002 at 11:36:42PM +0930, Alan Modra wrote:
> Oh, wait a minute.  That branch to baz is actually a branch to baz

Fired that off too quickly.  My explanation covers why we need to
use binds_local_p, not why TREE_ASM_WRITTEN is necessary.  So
back to that question again..

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: rs6000 sibcall test

[Richard Henderson]

On Fri, Sep 06, 2002 at 11:47:04PM +0930, Alan Modra wrote:
> Fired that off too quickly.  My explanation covers why we need to
> use binds_local_p, not why TREE_ASM_WRITTEN is necessary.  So
> back to that question again..

The only explanation must be that the assumption of
branch in range.  If the linker takes care of that,
you're fine.  It doesn't on Alpha.


r~

Re: rs6000 sibcall test

[Alan Modra]

On Sat, Sep 07, 2002 at 07:53:36PM -0700, Richard Henderson wrote:
> On Fri, Sep 06, 2002 at 11:47:04PM +0930, Alan Modra wrote:
> > Fired that off too quickly.  My explanation covers why we need to
> > use binds_local_p, not why TREE_ASM_WRITTEN is necessary.  So
> > back to that question again..
> 
> The only explanation must be that the assumption of
> branch in range.  If the linker takes care of that,
> you're fine.  It doesn't on Alpha.

Thanks for the explanation!  In that case, I think we want the following.

	* config/rs6000/rs6000.c (function_ok_for_sibcall): Use binds_local_p.
	Respect longcall attributes.

This is a bug fix, so a reasonable candidate for inclusion in 3.3.

Index: gcc/config/rs6000/rs6000.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.371
diff -u -p -r1.371 rs6000.c
--- gcc/config/rs6000/rs6000.c	7 Sep 2002 00:19:27 -0000	1.371
+++ gcc/config/rs6000/rs6000.c	8 Sep 2002 08:12:10 -0000
@@ -9503,8 +9505,14 @@ function_ok_for_sibcall (fndecl)
 	    }
         }
       if (DEFAULT_ABI == ABI_DARWIN
-	  || (TREE_ASM_WRITTEN (fndecl) && !flag_pic) || !TREE_PUBLIC (fndecl))
-        return 1;
+	  || (*targetm.binds_local_p) (fndecl))
+	{
+	  tree attr_list = TYPE_ATTRIBUTES (TREE_TYPE (fndecl));
+
+	  if (!lookup_attribute ("longcall", attr_list)
+	      || lookup_attribute ("shortcall", attr_list))
+	    return 1;
+	}
     }
   return 0;
 }


Just for the record, David pointed out another case where sibling calls
in PowerPC64 shared libs could go awry.  If "f1" in a shared lib calls
a local function "f2", then allowing the tail call optimisation from
"f2" to a global function "f3" will cause Horrible Things to happen.
The problem is that the f1 to f2 call _doesn't_ go via a stub, the toc
pointer isn't saved or restored (because f1 and f2 have the same toc
pointer), and when f3 returns (all the way back to f1) we may have a
different toc pointer.  Boom.

With a little extra linker support on powerpc64-linux, we can do

calling func   called func   sibling call OK
   any            local           yes
   local          global          no
   global         global          yes

ie. the last line is an extra case not allowed by this patch.
After 3.3 branches, maybe..

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: rs6000 sibcall test

[Richard Henderson]

On Sun, Sep 08, 2002 at 06:13:37PM +0930, Alan Modra wrote:
> 	* config/rs6000/rs6000.c (function_ok_for_sibcall): Use binds_local_p.
> 	Respect longcall attributes.

Does the linker add the jumps for ppc32 as well?



r~

Re: rs6000 sibcall test

[Alan Modra]

On Sun, Sep 08, 2002 at 11:00:06AM -0700, Richard Henderson wrote:
> On Sun, Sep 08, 2002 at 06:13:37PM +0930, Alan Modra wrote:
> > 	* config/rs6000/rs6000.c (function_ok_for_sibcall): Use binds_local_p.
> > 	Respect longcall attributes.
> 
> Does the linker add the jumps for ppc32 as well?

No.  Then again, it doesn't add long jumps for the powerpc call insn
either, which has the same displacement limitations as a plain branch.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre