Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Teemu Torma]

It seems that ASM_OUTPUT_MI_THUNK in sparc emits normal funcion call
sequence when the file compiled is compiled with -fpic.  This sounds
very slow, since the call goes thru the dynamic table and can lead to
an additional register window trap.

Is there any reason why not to emit the thunk to a writable segment?
In that case -fpic condition could be taken away.

Besides, the current test does not help if the main program compiled
without -fpic emits thunks that call methods in a shared library.

Teemu

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Richard Henderson]

On Tue, Nov 18, 1997 at 05:04:33PM +0100, Teemu Torma wrote:
> Is there any reason why not to emit the thunk to a writable segment?

Yes, there is a better way.

> Besides, the current test does not help if the main program compiled
> without -fpic emits thunks that call methods in a shared library.

Absolutely correct.


r~



Tue Nov 18 12:21:54 1997  Richard Henderson  <rth@cygnus.com>

	* sparc.h (ASM_OUTPUT_MI_THUNK): Move %o7 through %g1 instead of
	save+restore.  Fix pic+big_offset delay slot.  Use "pic" case for
	unix always, since we want to be able to thunk to functions in a
	shared library from an application.

Index: gcc/config/sparc/sparc.h
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/config/sparc/sparc.h,v
retrieving revision 1.10
diff -u -p -d -r1.10 sparc.h
--- sparc.h	1997/10/24 19:36:54	1.10
+++ sparc.h	1997/11/18 20:21:30
@@ -3016,11 +3016,15 @@ do {									\
   int big_delta = (DELTA) >= 4096 || (DELTA) < -4096;			\
   if (big_delta)							\
     fprintf (FILE, "\tset %d,%%g1\n\tadd %%o0,%%g1,%%o0\n", (DELTA));	\
-  if (flag_pic)								\
+  /* Don't use the jmp solution unless we know the target is local to	\
+     the application or shared object.  				\
+     XXX: Wimp out and don't actually check anything except if this is	\
+     an embedded target where we assume there are no shared libs.  */	\
+  if (!TARGET_CM_EMBMEDANY || flag_pic)					\
     {									\
       if (! big_delta)							\
 	fprintf (FILE, "\tadd %%o0,%d,%%o0\n", DELTA);			\
-      fprintf (FILE, "\tsave %%sp,-112,%%sp\n");			\
+      fprintf (FILE, "\tmov %%o7,%%g1\n");				\
       fprintf (FILE, "\tcall ");					\
       assemble_name							\
 	(FILE, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (FUNCTION)));	\
@@ -3043,10 +3047,10 @@ do {									\
 	(FILE, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (FUNCTION)));	\
       fprintf (FILE, ")\n");						\
     }									\
-  if (big_delta)							\
+  if (!TARGET_CM_EMBMEDANY || flag_pic)					\
+    fprintf (FILE, "\tmov %%g1,%%o7\n");				\
+  else if (big_delta)							\
     fprintf (FILE, "\tnop\n");						\
-  else if (flag_pic)							\
-    fprintf (FILE, "\trestore\n");					\
   else									\
     fprintf (FILE, "\tadd %%o0,%d,%%o0\n", DELTA);			\
 } while (0)

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Jeffrey A Law]

  In message <19971118122627.16484@dot.cygnus.com>you write:
  > Tue Nov 18 12:21:54 1997  Richard Henderson  <rth@cygnus.com>
  > 
  > 	* sparc.h (ASM_OUTPUT_MI_THUNK): Move %o7 through %g1 instead of
  > 	save+restore.  Fix pic+big_offset delay slot.  Use "pic" case for
  > 	unix always, since we want to be able to thunk to functions in a
  > 	shared library from an application.
Richard -- is there any reason not to install this patch?  If not, then
go ahead and install it.

jeff

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Richard Henderson]

On Wed, Dec 17, 1997 at 12:23:32AM -0700, Jeffrey A Law wrote:
>   > 	* sparc.h (ASM_OUTPUT_MI_THUNK): Move %o7 through %g1 instead of
> Richard -- is there any reason not to install this patch?  If not, then
> go ahead and install it.

Done.


r~

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Jeffrey A Law]

  In message < 199711210055.TAA00405@jfc. >you write:
  > This is another thing we shouldn't be touching at so late in the
  > release cycle.  I have some changes I was planning to send after the
  > release.
Agreed.  This can wait.
jeff

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Richard Henderson]

On Thu, Nov 20, 1997 at 07:55:29PM -0500, John Carr wrote:
> On SPARC processors other than UltraSPARC call is at least as fast as
> jmpl.

True, but the issue in the case of the thunk is not jmpl vs call
per se, but eliminating the two runtime relocations needed when
the sethi+jmpl references a symbol in a shared library.

> On UltraSPARC using a call without a matching return confuses
> the return prediction stack.  It takes an extra 2-4 cycles to fetch
> the correct set of instructions.  (For this reason, I think the recent
> change to use call instead of rd %pc for V9 PIC was wrong even though
> rd takes longer to execute.)

But rd %pc not only has 5 ticks latency, it inserts 4 bubbles as
well, so nothing else gets done.  I'll leave it to the experts,
but trading off 2-4 cycles of branch mispredict is a close thing.


r~

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[John Carr]

> Well, I suppose we could use call in all cases.  That would simplify the
> code.  Does anyone with more SPARC experience have an opinion?

On SPARC processors other than UltraSPARC call is at least as fast as
jmpl.  On UltraSPARC using a call without a matching return confuses
the return prediction stack.  It takes an extra 2-4 cycles to fetch
the correct set of instructions.  (For this reason, I think the recent
change to use call instead of rd %pc for V9 PIC was wrong even though
rd takes longer to execute.)

This is another thing we shouldn't be touching at so late in the
release cycle.  I have some changes I was planning to send after the
release.

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Jason Merrill]

>>>>> Richard Henderson <rth@cygnus.com> writes:

> Normal function calls use call not sethi+jmp.  The former case gets
> fixed up to a call through the PLT, the later results in runtime
> relocations to the read-only text segment.  Which works, but slows down
> startup unnecessarily.

Well, I suppose we could use call in all cases.  That would simplify the
code.  Does anyone with more SPARC experience have an opinion?

Jason

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Richard Henderson]

On Tue, Nov 18, 1997 at 09:33:45AM -0800, Jason Merrill wrote:
> > Besides, the current test does not help if the main program compiled
> > without -fpic emits thunks that call methods in a shared library.
> 
> Huh?  How is this different from any other function that calls functions in
> a shared library?

Normal function calls use call not sethi+jmp.  The former case gets
fixed up to a call through the PLT, the later results in runtime
relocations to the read-only text segment.  Which works, but slows down
startup unnecessarily.


r~

Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc

[Jason Merrill]

>>>>> Teemu Torma <tot@trema.com> writes:

> It seems that ASM_OUTPUT_MI_THUNK in sparc emits normal funcion call
> sequence when the file compiled is compiled with -fpic.  This sounds
> very slow, since the call goes thru the dynamic table and can lead to
> an additional register window trap.

It uses a normal function call because that's the only way to get the
appropriate relocs for PIC code.  There is no jmp that uses the procedure
linkage table.

> Is there any reason why not to emit the thunk to a writable segment?
> In that case -fpic condition could be taken away.

I suppose, but I can't imagine that a function call is as slow as all that.

> Besides, the current test does not help if the main program compiled
> without -fpic emits thunks that call methods in a shared library.

Huh?  How is this different from any other function that calls functions in
a shared library?

Jason