Re: egcs-19980803 (pre-1.1) solaris regressions

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

   Date: Tue, 18 Aug 1998 11:03:38 -0600
   From: Jeffrey A Law <law@hurl.cygnus.com>

   Yea.  This is nightmare code to deal with too.  The ability to clean
   up this mess is one of the big wins if we recompute live/dead and
   block start/end info after reload.

Indeed, and I still want to implement pre-delay slots for sake of
Sparc FPU branches as well...

   Hmm.  Presumably the usage of the PIC register happens behind reload's
   back.  ie, the pic reg is not a spill register and it's not already
   mentioned elsewhere in the function before reload?

It gets used behind reloads back, and it is acquired for register
allocation as well.  It is fine to use it normally before register
allocation, but if reload_in_progress we should note what we are
doing.

   In that case I think it is the backend's responsibility to note that
   the PIC register is in-use.

So I should update basic_block_live_at_start, or other things as well?

   Note that having the PIC register come live behind reload's back can
   lead to some problems.  We've run into this on the PA, m68k, x86 and ppc.

Do other ports handle this by updating the alloc/reload tables?  I
should go check what other people do wrt. this.  I don't want to mark
it as not allocatable at all.  (a quick check shows that ix86 marks it
as fixed, aieee thats nuts!)

   Hopefully your PIC register is fixed and not a pseudo?  And hopefully,
   you always allocate a stack slot for it when -fpic/-fPIC?

It is fixed (but rth and I want to change this so functions which use
PIC can still be made leaf functions).  I need to go over how we do
all of this on Sparc, LEGITIMATE_PIC_OPERAND_P seems suspicious at the
moment and actually could be the true root of the problem I am seeing
here.

   targ

An emacs abbrev-mode fart? :-)

Later,
David S. Miller
davem@dm.cobaltmicro.com