Fix for IRA stack slot sharing codegen but on BYTES_BIG_ENDIAN targets

Jeff Law law@redhat.com
Tue Sep 9 07:51:00 GMT 2008


Richard Guenther wrote:
> On Sat, Sep 6, 2008 at 11:07 PM, Jeff Law <law@redhat.com> wrote:
>   
>> There are several testsuite regressions when using IRA on the H8 port.
>>
>>
>> The underlying problem is IRA will record the wrong address for a slot on a
>> BYTES_BIG_ENDIAN target when two nonconflicting pseudos with different sizes
>> are sharing a slot.
>> So, assume we have two registers, A -- HImode and B -- SImode that do not
>> conflict and can share a slot.  Assume we encounter A first.  We correctly
>> allocate enough space for SImode, say at fp - 12.  But an endianness
>> adjustment is performed in assign_stack_local so the returned address is
>> actually fp - 10.  That's the address IRA records.  Later when we want the
>> slot for B, we find the shared slot fp - 10.   Obviously storing B into fp
>>  - 10 writes into part of the slot shared by A & B as well as the nearby
>> memory locations fp -8 and fp - 7, which is very very very bad.
>>
>> The non-IRA codepath undoes the endianness adjustment before recording a
>> slot for sharing purposes.  The IRA codepath seems to have part, but not all
>> of the code necessary to undo the endianness adjustment.  This patch adds
>> the missing code to the IRA path.
>>
>> This has not been checked in as it is awaiting review by a reload
>> maintainer, global reviewer...
>>     
>
> I think it would make sense to have an extra parameter to assign_stack_local
> to return this unadjusted slot.  This would save us some code duplication at
> least.
>   
I thought about that, but what we'd really need is for 
assign_stack_local to return two values.  One adjusted and one 
unadjusted as the stack slot sharing code needs both variants.  Seemed 
to be more pain that it was worth given the non-IRA path won't be around 
much longer.



Jeff



More information about the Gcc-patches mailing list