-----Original Message----- From: Richard Sandiford [mailto:richard.sandif...@arm.com] Sent: Monday, September 22, 2014 4:56 PM To: Ajit Kumar Agarwal Cc: Jeff Law; gcc-patches@gcc.gnu.org Subject: Re: [PATCH 0/5] Fix handling of word subregs of wide registers
Ajit Kumar Agarwal <ajit.kumar.agar...@xilinx.com> writes: > Jeff Law <l...@redhat.com> writes: >> On 09/19/14 01:23, Richard Sandiford wrote: >>> Jeff Law <l...@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 for the explanation. Thanks, Richard
