This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [I don't think it's off-topic at all] Linking speed for C++


On Wed, May 09, 2001 at 11:39:04AM -0700, Joe Buck wrote:
> > Clearly, if the pointer points to a global symbol that is defined
> > externally, we we still need a relocation.  But it will be common to refer
> > to a function whose definition comes from the same object file, or the
> > same .so (meaning that relocations can be eliminated when building the
> > shared library).
> 
> No, you misunderstand.  If the symbol is _visible_ externally, then a
> dynamic relocation is required.  Even if the actual definition comes
> from the current dso.  This is just the way ELF dynamic linking works.

It seems that this should be fixable by making the linker smarter.  After
all, for the case of an offset to the same dso, what we have is a
constant.  What will this required dynamic relocation do?  There is
nothing to relocate, nothing to compute!  When we do gcc -shared, we wind
up with an .so that has some relocation expressions in which the
relocations cancel.  Why can't they be constant-folded, so when this .so
is linked to at runtime, no relocation is left?

> > So it seems to me that at least some (though not all) relocations can be
> > made to disappear on all platforms.
> 
> If you can't get rid of them all, then you can't make them read-only.

True, but this started from a discussion that showed that startup time
was proportional to the number of relocations that must be performed
at startup time.  Startup speed increases if the number of needed
relocations decrease.  We don't have to go to zero to see a benefit.

> > This would require an extra instruction on the sparc but not the x86
> > (though there could still be a penalty on the x86 because use of the
> > ALU affects ILP).
> 
> Yes.  Oh well.  Whaddaya want, something for nothing?  ;-)

Well, in this case (for the x86) it seems we can come close, as the
beginning of the called function is going have mostly moves, not ALU use,
for the first few instructions, so the extra addition might well be free
in most cases.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]