This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Handling of libgcc symbols in SH shared libraries
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: aoliva at redhat dot com (Alexandre Oliva)
- Cc: joern dot rennecke at superh dot com (Joern Rennecke), gcc at gcc dot gnu dot org, kkojima at rr dot iij4u dot or dot jp (Kaz Kojima), amylaar at spamcop dot net
- Date: Wed, 11 Aug 2004 12:35:50 +0100 (BST)
- Subject: Re: RFC: Handling of libgcc symbols in SH shared libraries
> On Aug 2, 2004, Joern Rennecke <joern.rennecke@superh.com> wrote:
>
> > For now, for SFUNC_GOT, I always make function_symbol generate
> > @GOT addressing, although for most functions that is not strictly
> > necessary: they could use @PLT addressing, as long as it is guaranteed
> > that the symbol is resolved at load time (or earlier with pre-linking).
>
> But why would you want @PLT addressing instead of @GOT addressing? It
> would have a performance impact, since the @PLT code would just do the
> load from GOT and jump to the loaded address (with a possible pipeline
> stall on the memory load), whereas if you load the address from the
> GOT and call it directly you can schedule better. Sure, it's one
> additional instruction per call, so it may have negative code size and
> thus cache effects. How badly would you like to get rid of it?
Well, I thought that if one wanted fast code, you would choose SHmedia
code and faster division options to start with.
So the SHcompact support functions and the fully-encapsulated divide seem
good candidates to use @PLT, if you can avoid unexpected register clobbers
from lazy linking.