This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
potential x86 pic optimization.
- To: egcs at cygnus dot com
- Subject: potential x86 pic optimization.
- From: Robert Lipe <robertl at dgii dot com>
- Date: Wed, 1 Jul 1998 11:19:57 -0500
I've been staring at the failures with -fPIC on 921215-1.c and after
some discussion with one of the SCO compiler chain wizards, we reached
two conclusions:
* SCO's linker does the wrong thing in this case. (It's likely that
it does so for all of {OpenServer, UnixWare 7, Unixware 2}.)
* The assembler source that triggers it is suboptimal.
In the assembler source, when loading up the trampolines, EGCS emits
code of the form:
movl .LTRAMP0@GOT(%ebx),%ecx
movl %ecx,%edx
.LTRAMP0 is a local (non-global) symbol. However, GAS seems to make an
exception for this case and definitely *does* put this entry in the symbol
table. In this example, blahgas and blahsco are the linker output of the
output from the same assembler file passed to the respective assemblers.
$ nm blahgas | grep -i tramp
[57] | 134514172| 0|NOTY |LOCL |0 |8 |.LTRAMP0
(robertl) rjldell:/home/robertl/tmp/negcs/gcc
$ nm blahsco | grep -i tramp
(robertl) rjldell:/home/robertl/tmp/negcs/gcc
$
My cohort suggests that replacing that first movl with:
leal .LTRAMP0@GOTOFF(%ebx),%ecx
would result in getting tha address of .LTRAMP0 into %ecx without
needing a GOT entry and without reading memory.
Is this a worthwhile optimization for someone comfortable inside i386.c
and i386.md to do? I haven't run down all the bizarre -fPIC failures
yet, but the several I checked were all of this form.
Thanx.
RJL