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]

potential x86 pic optimization.


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


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