Re: dynamic PIC register?

[Geoff Keating <geoffk at geoffk dot org>]

David Edelsohn <dje@watson.ibm.com> writes:

> >>>>> dalej  writes:
> 
>> On the Darwin powerpc target, it would be better not to have
>> PIC_OFFSET_TABLE_REGNUM be a fixed register.  In particular, it
>> should be a register saved over calls in a non-leaf function, and a
>> register not saved over calls in a leaf function.  I could do this
>> by changing the fixed register at the last minute in the
>> target-dependent prolog/epilog generation (which is what we did in
>> the 2.95 version currently shipping).  But it seems to me a cleaner
>> solution that also applies to other targets might be useful.  Is
>> this so, and how might I go about it?
> 
> 	I thought that Geoff and/or Franz explored this for the 32-bit
> PowerPC SVR4 GOT register and found this was not practical, but I don't
> remember the details.  Maybe the impediment no longer exists.

The reason for the current implementation is that the places where the
register is used can vary until reload is complete (including the case
where it appears to not be used and then a use appears).  I believe
that I even found a case where it could appear in the jump pass after
reload, but since all that code's now gone I hope it shouldn't happen
any more.

The clean solution is to have register allocation just allocate this
like any other register; this would give better code (on SVR4) for
functions like

extern foo;

if (foo)
  return bar();
else
  return 1;

because this function shouldn't need any call-saved registers either,
as the GOT register isn't live after the call.

I wouldn't object to a patch like the one dalej has in the 2.95
version, so long as it's clean.  There is likely to be some rewriting
needed since the prolog/epilog generation has been changed to use RTL.

-- 
- Geoffrey Keating <geoffk@geoffk.org>