dynamic PIC register?

dynamic PIC register?

[dalej]

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?

Re: dynamic PIC register?

[David Edelsohn]

>>>>> dalej  writes:

Dale> On the Darwin powerpc target, it would be better not to have 
Dale> PIC_OFFSET_TABLE_REGNUM be a fixed register.  In particular, it should be 
Dale> a register saved over calls in a non-leaf function, and a register not 
Dale> saved over calls in a leaf function.  I could  do this by changing the 
Dale> fixed register at the last minute in the target-dependent prolog/epilog 
Dale> generation (which is what we did in the 2.95 version currently shipping).  
Dale> But it seems to me a cleaner solution that also applies to other targets 
Dale> 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.

David

Re: dynamic PIC register?

[Geoff Keating]

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>

Re: dynamic PIC register?

[Alexandre Oliva]

On Sep 20, 2001, dalej@apple.com wrote:

> On the Darwin powerpc target, it would be better not to have
> PIC_OFFSET_TABLE_REGNUM be a fixed register.

I don't know anything about the implementation of shared libraries on
ppc, but if it uses a procedure linkage table, I don't see how the PIC
register may vary: the PLT in general depends on a specific register
pointing to the GOT (plus or minus some constant).  It would be nice
to be able to have the fixed register used only in these cases,
though, and leave it up to the register allocator to take care of
cases that don't involve the PLT, such as GOT loads.

But maybe none of this applies to PowerPC.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: dynamic PIC register?

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

Alexandre Oliva <aoliva@redhat.com> writes:

|> On Sep 20, 2001, dalej@apple.com wrote:
|> 
|> > On the Darwin powerpc target, it would be better not to have
|> > PIC_OFFSET_TABLE_REGNUM be a fixed register.
|> 
|> I don't know anything about the implementation of shared libraries on
|> ppc, but if it uses a procedure linkage table, I don't see how the PIC
|> register may vary: the PLT in general depends on a specific register
|> pointing to the GOT (plus or minus some constant).

On the m68k the PLT does not depend on a PIC register at all (it gets the
address of the GOT by pc-relative addressing).  So it would benefit from a
non-fixed PIC register as well.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: dynamic PIC register?

[Stan Shebs]

Alexandre Oliva wrote:
> 
> On Sep 20, 2001, dalej@apple.com wrote:
> 
> > On the Darwin powerpc target, it would be better not to have
> > PIC_OFFSET_TABLE_REGNUM be a fixed register.
> 
> I don't know anything about the implementation of shared libraries on
> ppc, but if it uses a procedure linkage table, I don't see how the PIC
> register may vary: the PLT in general depends on a specific register
> pointing to the GOT (plus or minus some constant).

No PLT or GOT.  The PIC register is set up per-function.  The Darwin
PIC strategy is unlike any other, one reason why there is a lot of code
in config/darwin.*.

Stan