This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc
- To: John Carr <jfc at tiac dot net>
- Subject: Re: Handling of -fpic in ASM_OUTPUT_MI_THUNK in sparc
- From: Richard Henderson <rth at cygnus dot com>
- Date: Thu, 20 Nov 1997 20:54:55 -0800
- Cc: Jason Merrill <jason at cygnus dot com>, Teemu Torma <tot at trema dot com>, egcs at cygnus dot com, "David S. Miller" <davem at dm dot cobaltmicro dot com>, jj at sunsite dot ms dot mff dot cuni dot cz
- References: <u967ppmy3n.fsf@yorick.cygnus.com> <199711210055.TAA00405@jfc.>
- Reply-To: Richard Henderson <rth at cygnus dot com>
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~