Re: [PATCH 0/5] Fix handling of word subregs of wide registers

[Jeff Law <law@redhat.com>]

On 09/19/14 01:23, Richard Sandiford wrote:
> Jeff Law <law@redhat.com> writes:
>> On 09/18/14 04:07, Richard Sandiford wrote:
>>> This series is a cleaned-up version of:
>>>
>>>       https://gcc.gnu.org/ml/gcc/2014-03/msg00163.html
>>>
>>> The underlying problem is that the semantics of subregs depend on the
>>> word size.  You can't have a subreg for byte 2 of a 4-byte word, say,
>>> but you can have a subreg for word 2 of a 4-word value (as well as lowpart
>>> subregs of that word, etc.).  This causes problems when an architecture has
>>> wider-than-word registers, since the addressability of a word can then depend
>>> on which register class is used.
>>>
>>> The register allocators need to fix up cases where a subreg turns out to
>>> be invalid for a particular class.  This is really an extension of what
>>> we need to do for CANNOT_CHANGE_MODE_CLASS.
>>>
>>> Tested on x86_64-linux-gnu, powerpc64-linux-gnu and aarch64_be-elf.
>> I thought we fixed these problems long ago with the change to subreg_byte?!?
>
> No, that was fixing something else.  (I'm just about old enough to remember
> that too!)  The problem here is that (say):
>
>      (subreg:SI (reg:DI X) 4)
>
> is independently addressable on little-endian AArch32 if X assigned
> to a GPR, but not if X is assigned to a vector register.  We need
> to allow these kinds of subreg on pseudos in order to decompose multiword
> arithmetic.  It's then up to the RA to realise that a reload would be
> needed if X were assigned to a vector register, since the upper half
> of a vector register cannot be independently accessed.
>
> Note that you could write this example even with the old word-style offsets
> and IIRC the effect would have been the same.
Maybe I've got some kind of mental block here.  I'll go back and read 
the manual first and see if that helps :-)

jeff