RFA: patch to solve PR37535

Bernd Schmidt bernds_cb1@t-online.de
Thu Sep 25 21:22:00 GMT 2008


Jeff Law wrote:
> John David Anglin wrote:
>>> I guess my first question would be what code ultimately selects r4 to 
>>> hold something other than the saved PIC register?  Was it allocation 
>>> or reloading?
>>>     
>>
>> I believe the selection was by allocation.  In the dump, the register
>> is "reg/v:DI 4 %r4 [orig:145 i+-4 ] [145]".
>>   
> OK.
>>> I have vague memories of code which prevented allocation/reloading 
>>> from using explicitly mentioned hard registers to hold values, but I 
>>> couldn't find it after a quick scan today.
>>>     
>>
>> If I remember correctly, the original scheme allocated a pseudo, and
>> saved and restored the PIC register using the pseudo.  The code was
>> subject to scheduling.  In practice, this relied on call groups to
>> work.  However, we hit a bug where a load which implicitly used the
>> PIC register was scheduled before the restore.
>>   
> Yea.  That sounds vaguely familiar as well.
> 
> My prior comment was about generic code in the allocator/reload to avoid 
> using explicitly mentioned hard regs to hold values.  The more I think 
> about it, the more I think Bernd zapped that code as a side effect of 
> his local spilling changes many many years ago.

IIRC there used to be code that globally prevented any explicitly 
mentioned hard reg to be used for spills, except on 
SMALL_REGISTER_CLASSES machines.  I removed that, but now the live info 
in the insn_chain structure should hold local information for every 
insn.  An explicit clobber of a hard reg should make that hard reg 
unavailable for anything else in the insn.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif



More information about the Gcc-patches mailing list