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

[Richard Sandiford <richard.sandiford@arm.com>]

Ajit Kumar Agarwal <ajit.kumar.agarwal@xilinx.com> writes:
> Jeff Law <law@redhat.com> writes:
>> 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.
>> OK.  So I kept thinking in terms of the byte offset stuff.  But what 
>> you're tackling is related to the mess around the mode of the subreg 
>> having a different meaning if its smaller than a word vs word-sized or 
>> greater.
>>
>> Right?
>
>>>Yeah, that's right.  Addressability is based on words, which is
>>> inconvenient when your registers are bigger than a word.
>
> If the architecture like Microblaze which doesn't support the 1 byte or
> 2 byte registers. In this scenario what should be returned when
> SUBREG_WORD is used.

I don't understand the question sorry.  Subreg offsets are still represented
as bytes rather than words.  The patch doesn't change the way that subregs
are represented or the rules about which subregs are valid.

Both before and after the patch, the semantics of subregs say that if
you have 4-byte words, only one of:

    (subreg:QI (reg:SI X) 0)
    (subreg:QI (reg:SI X) 1)
    (subreg:QI (reg:SI X) 2)
    (subreg:QI (reg:SI X) 3)

is ever valid (0 for little-endian, 3 for big-endian).  Writing to that
one valid subreg will change the whole of X, unless the subreg is wrapped
in a strict_lowpart.  In other words, subregs are defined so that individual
parts of a word are not independently addressable.

However, individual words of a multiword register _are_ addressable.  I.e.:

   (subreg:SI (reg:DI Y) 0)
   (subreg:SI (reg:DI Y) 4)

are both valid.  Writing to one does not change the other.

The problem the patch was trying to solve was that you can have targets
with 4-byte words but some 8-byte registers.  In those cases, it's still
possible to form both of the Y subregs above if Y is allocated to a word-sized
register, but not if Y is allocated to a doubleword-sized register.

Thanks,
Richard