Oust HPPA PIC_OFFSET_TABLE_REGNUM_SAVED

[Jeffrey A Law]

  In message <200101151624.LAA26183@hiauly1.hia.nrc.ca>you write:
  > > This patch rids us of PIC_OFFSET_TABLE_REGNUM_SAVED, and the problems tha
  > t
  > > go with it.  Additionally, I reload the pic offset table register before
  > > calls to guard against asm trashing r27/r19.  Hasn't bootstrapped yet, bu
  > t
  > > looks promising.  One possible fly in the ointment is whether any ABI
  > > requires that r4 always be used to save the pic offset table reg.
  > 
  > At first glance, this looks like a good solution.  I don't see any
  > requirementthat r4 be used to save the pic offset table reg in either ABI.
It is not an ABI requirement.  It was done because GCC was unable 
reasonably cope with a PIC register that was call-clobbered.

  > However, why is it necessary to guard against asms trashing r27/r19?  If
  > this happens, data access using gp won't work as well.  Shouldn't asms
  > ensure that they restore r27/r19 if they trash it?  If in fact r27/r19
  > needs to be restored prior to calls, it looks like it also needs to be
  > restored prior to each procedure return (see below).  This would prevent
  > the trivial return from ever being generated whenever pic code is used.
  > Thus, it seems necessary to ensure that r27/r19 is preserved from entry
  > to exit.
If an ASM trashes a fixed register, then the ASM is responsible for restoring
it.

jeff