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

[Michael Meissner <meissner at cygnus dot com>]

| 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).

Yep, and people use it (though one of our customers is using the -msdata=sysv
option, and using r2 as a thread pointer).

| 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.

Well if it is rare, you could always use the same register for the load
register.  You still have the problem that LR is trashed, and reload might be
keeping something else in it (such as an address it is about to jump to).