pa reload problem

[Alan Modra]

On Fri, 1 Dec 2000, John David Anglin wrote:

> >         b,l foo,%r2
> >         copy %r27,%r4
> >         addil LT'cpu_hz,%r4	! know r27 trashed in call, so use r4
> >         ldd RT'cpu_hz(%r1),%r1
> >         ldd -144(%r30),%r2
> >         ldw 0(%r1),%r19
> >         addil LT'L$C0000,%r27	! oops, should be using r4
> >         ldd RT'L$C0000(%r1),%r1
> 
> It looks to me like this happens because the register life analysis in
> pass 13 decides that r27 (dp) is dead.  This causes combine to delete the
> insn that restores r27 after the call to foo and use the value saved
> in r4 as a proxy for dp.

Yes.

> (insn 16 14 21 (set (reg:DI 27 %r27)
>         (reg:DI 4 %r4)) 123 {movstrsi_internal+11} (nil)
>     (expr_list:REG_DEAD (reg:DI 4 %r4)
> 	(nil)))
> 
> (insn 21 16 23 (set (reg:DI 68)
> 	(plus:DI (reg:DI 27 %r27)
> 	    (high:DI (symbol_ref:DI ("cpu_hz"))))) 81 {post_std+3} (insn_list 16 (nil))
>      (expr_list:REG_DEAD (reg:DI 27 %r27)
> 	(nil)))
> 
> The const_int's which follow haven't been expanded at this point.  Thus,
> the life analysis can't tell that r27 is still needed.

Exactly.  So how is the code in pa.c to know that PIC_OFFSET_TABLE_REGNUM 
has been clobbered - and should use PIC_OFFSET_TABLE_REGNUM_SAVED instead?
Using the saved version should be safe as it is a fixed reg.

Or is a better solution to simply ensure that r27 never dies?  I'm
thinking of ABI and (non-gnu) linker considerations.  eg. DLTIND21L relocs
not involving r27 may cause something to barf.

Alan
-- 
Linuxcare.  Support for the Revolution.