Vladimir Makarov <vmaka...@redhat.com> writes:
> On 12/08/2012 05:30 AM, Richard Sandiford wrote:
>> Vladimir Makarov <vmaka...@redhat.com> writes:
>>> Index: lra-constraints.c
>>> ===================================================================
>>> --- lra-constraints.c (revision 194307)
>>> +++ lra-constraints.c (working copy)
>>> @@ -3329,8 +3329,9 @@ lra_constraints (bool first_p)
>>> reg = regno_reg_rtx[i];
>>> if ((hard_regno = lra_get_regno_hard_regno (i)) >= 0)
>>> {
>>> - int j, nregs = hard_regno_nregs[hard_regno][PSEUDO_REGNO_MODE (i)];
>>> + int j, nregs;
>>>
>>> + nregs = hard_regno_nregs[hard_regno][lra_reg_info[i].biggest_mode];
>>> for (j = 0; j < nregs; j++)
>>> df_set_regs_ever_live (hard_regno + j, true);
>> It looks like this loop now iterates over a different mode from the
>> pseudo register's, but starts at the hard register allocated to the
>> pseudo. That doesn't work on big-endian targets, where the "extra"
>> registers come before hard_regno. I think you need to use
>> simplify_subreg_regno (...subreg_lowpart_offset (...)).
>> I realise we only support little-endian for 4.8, but still.
> Yes, Richard, I am aware about it. There are a few places in LRA where
> similar code should be fixed for big-endian targets. I'd like to
> address this problem on lra-branch when I am less busy.
Well, OK, but in the meantime how about putting asserts like:
gcc_assert (!BYTES_BIG_ENDIAN)
in the affected places? I'm just worried that this kind of thing leads
to subtle wrong-code bugs in hard-to-reduce cases, so an assert would
make it easier to track which places need updating.
Richard
