Re: i386/PIC optimization

[Jan Hubicka <jh at suse dot cz>]

> > It is not at all clear to my why GOT is forced for calls trought PLT table,
> > since it is also addressed instruction pointer relative...
> 
> The PIC PLT entry needs it.  Examine a sample entry from libc:
> 
>    16a94:       ff a3 0c 00 00  jmp    *0xc(%ebx)
>    16a99:       00 
>    16a9a:       68 00 00 00 00  push   $0x0
>    16a9f:       e9 e0 ff ff ff  jmp    16a84 <GLIBC_2.0+0x16a84>

Duh...  I've examined and missed the (%ebx) there.
> 
> <16a94> is the plt address.  It loads an entry from the .plt.got
> (which gets merged into the .got section) and jumps to it.  Note
> that it assumes %ebx is correct for the current module.
OK.
Is there any purposes why instruction pointer relative jump isn't
used here? 
Is that to support loading of data and text segments of shared library
to diferent places? Is that required?
> 
> The initial value of the .plt.got entry is <16a9a>, which makes
> its way into the dynamic linker to do lazy binding.  There, ld.so
> overwrites the .plt.got entry so that the next time though this
> PLT entry we proceed directly to the final destination.
Yes, I am aware of that mechanizm. I just tought it is doable
w/o the GOT pointer using relative jumps and missed that bit in
dissassembly and missed the actual %ebx bit in disassembly.

I am now participating on designing new ABI so I am trying to understand all
details of that and see if the need of inter-procedural GOT pointer can be
easilly eliminated.
> 
> > If it is not necesary, we can probably use reg_ever_live to determine
> > whether calculation is EBX is necesary or not and avoid it even for
> > function, where global references was eliminated during the optimization.
> 
> Possibly.  It is notoriously tricky working around reload for this.
OK.
Is there someone doing that tricks so I can copy the code?
> 
> Another thing that can be done involves multiple entry points -- one
> that computes %ebx, and one that assumes that it's already correct.
I already tought about this too.
If I remember correctly, you was mentioning that Cygnus has implemented
something like this for MMX/EMMS instructions.  So my plan is wait for
Bernd's merger before getting to this.
> Next, we do whole-translation unit inspection to determine that a
> static function cannot be called from outside the translation unit,
> and so the "normal" entry point isn't needed.
Perhaps this can be done by garbage-collecting linker, but it would
be probably costy and we will get to problems with alignments of
beggining of sections....
> 
> > 	* i386.md (call_pop, call, call_value_pop): Do not set
> > 	current_function_uses_pic_offset_table for calls to static
> > 	functions or indirect calls.
> 
> Ok.
Thanks.

PS: Sorry for sending it twice - I am still getting problems with new
gcc-patches list address.

Honza
> 
> 
> r~