Philip Pemberton <[email protected]> writes:
>> The address is unusual:
>>
>> (subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
>> (const_int 64 [0x40])) [0 S8 A64]) 4)
>>
>> Why isn't that simply
>>
>> (mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ])
>> (const_int 68 [0x40])) [0 S8 A64])
>
> Let me see if I understand this right...
>
> It's using an SImode (machine-native size, 32 bit) subreg over a
> DImode (DWORD, 64bit) address of a 32-bit addition operation? That
> can't be right...
This means that it is taking an SImode slice out of a DImode value.
>> That makes it look like something is creating a subreg without going
>> through simplify_gen_subreg.
>>
>> It's also possible that the problem is simply that
>> lm32_legitimate_address_p needs to handle a SUBREG memory address.
>
> The questions raised by that would be:
> 1) Where is the subreg being created? (or: "how can a subreg be
> created?" -- then grep the lm32 source for the answer(s) to that
> question)
I don't know where the subreg is being created. There are several
different ways to create one.
> 2) (assuming [1] isn't the problem) How do you handle a SUBREG in
> *_legitimate_address_p?
In *_legitimate_address_p you can usually do something along the lines
of
if (GET_CODE (x) == SUBREG)
x = SUBREG_REG (x);
However, as I mentioned, this whole SUBREG is odd, so it's first
necessary to find out whether it should have been created at all.
Ian
