test results (mips-sgi-irix5.2)

[Jeffrey A Law]

  In message < 199709050237.TAA05724@cygnus.com >you write:
  > While trying to restore the execution context after a longjmp, it emits
  > RTL to restore the FP, and then it emits code to perform a call.  The call
  > is really not necessary.  However, on some systems, such as irix5 (and
  > perhaps the alpha), a function call as a side effect will cause the GP
  > (global pointer) register to be restored because the GP is always loaded
  > from the stack after a call.  Unfortunately, there is no explicit dependence
  > between a call insn and the fp register, so it is possible for the instruction
  > scheduler to move the fp restore after the call, which causes the gp register
  > to be corrupted because it is loaded from the wrong address.
This is actually similar to how we have to deal with the PIC register
between calls on the PA.

Basically the PIC register is call clobbered, and _must_ be reloaded after
a call, even if it isn't explicitly used (it can be used implicitly by
the next call).

We used to just restore it, but eventually found the scheduler moving too
many things around and/or the restore getting deleted as useless.

I ended up solving this in the same basic way -- a barrier after restoring
the PIC register.  Not pretty, but effective.

jeff