Re: Painful problems with -fpic implementation on powerpc-sysv

[Geoff Keating <geoffk at ozemail dot com dot au>]

> Date: Wed, 26 Aug 1998 22:57:28 -0400
> From: David Edelsohn <dje@watson.ibm.com>

> >>>>> Jeffrey A Law writes:
> 
> Jeff> It says:
> Jeff> Register r2 is reserved for system use and should not be changed by
> Jeff> application code.
> 
> Jeff> I don't know if that gives us the leeway we need to claim it.
> 
> 	Yeah, that's sort of what I remembered.  I have no idea what that
> means though I would think that GOT addressibility comes under system use
> and not application code.

In this context, 'system use' is the kernel and libc.  'applications'
are ELF executables and shared libraries that don't come with the
system.  For instance, it's allowed for the libc to clobber r2, which
might happen if AIX was doing a sysv ABI emulation; or to use r2 as a
thread ID, which is what I think the old pre-2.0 glibc does.

-fPIC uses register 30.  But this is really expensive, because it
means that even a trivial routine that uses one global data item has
to have a stack frame and has to save two registers (r30 and r31).
One of the nice things about -fpic is that accesses to global data do
not necessarily cause a leaf routine to have a stack frame.

> 	I would defer to Meissner as he has been involved with the PPC
> eABI which is a variant of PPC SVR4, so he should know how the committee
> intended r2 to be used.  If not r2, then I guess r30 would be the next
> best choice as that is used for the AIX "minimal-TOC" alternate TOC
> register which has similar requirements for an addressibility register
> allocated by the compiler if the ABI intended "system use" to mean
> something else.

I believe that the EABI defines r2 for accesses of small read-only
constant data, which is important for embedded code (r13 is
used by both ABIs for writable small data).


I don't think it's that hard to get the current powerpc -fpic
implementation working properly.  At worst, it might be necessary to,
under some circumstances, generate a new GOT register on-the-fly and
explain to reload that certain kinds of reloads require the link
register---you can always get the address of any global data by writing

  bl  _GLOBAL_OFFSET_TABLE_@local
  mflr %0
  lwz  %0,something@got(%0)

which requires two registers, one for the destination (which reload
already knows about) and the link register.  In pseudo-RTL, this looks
like

(set (reg 65 lr) (unspec [(const_int 0)] 7))
(set (reg %0) (reg 65 lr))
(set (reg %0) (unspec [(symbol_ref "something") (reg %0)] 8))

at the moment.

Of course, this is pretty expensive, requires two reload registers,
and I'm not sure how to explain it to reload.  But the need for it is
rare, and there are often (always?) other alternatives so it should
be possible to convince reload to do it very infrequently.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>