Re: [trunk] Addition to subreg section of rtl.text.

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

Hi Joern,

Thanks for the answer,

Joern Rennecke <joernr@arc.com> writes:
>> 1) Is it possible to have a MODE_PARTIAL_INT inner register that is bigger than a word?
>
> Yes.  You might have a 20 bit register, which is considered Pmode == PHImode,
> with a lower half QImode (16 bit, word addressed) which can be accessed
> separately by arithmetic instructions.

OK.

>> If so, what restrictions (if any) apply to subregs that access the
>> partial word? Is the inner register implicitly extended so that it is
>> a whole number of words? If not, are we effectively allowing
>> non-contiguous byte ranges when WORDS_BIG_ENDIAN != BYTES_BIG_ENDIAN?
>
> As far as GCC is concerned, the partial integer mode has the same size as
> the underlying integral mode, but the upper bits are undefined or defined
> in a machine-dependent manner.  That makes sense when you consider that in
> the example above, the 20 bit register has to be stored in a 32 bit memory
> location.  So as far as GCC is concerned, it is a value that is accomodated
> in the same storage space as a HImode value, hut some bits behave in a way
> it can't quite predict.
> Still, you can get two QImode halves out of a PHImode value.  Or you could
> choose to take two PQImode halves.
> At least that the theory.  I don't know if it still works, as a number of
> DSP processors have been removed in the last years, and some new ports
> were never contributed.
>
>> E.g., suppose we have a 16-bit WORDS_BIG_ENDIAN, !BYTES_BIG_ENDIAN
>> target in which PSImode is a 24-bit value. Is the layout of 0x543210
>> "45..0123"?
>
> The most natural layout would be 0x45??0123 .
> But you could also have 0x345?012? , or even more exotic mappings.

Do we actually support the second mapping though?  Surely the
target-independent code needs to know how bytes are divided into words?

The reason Kenny's looking at this is that he wants to track which
bytes in a SUBREG are actually live.

>> 2) Is it possible for the outer register in a normal subreg to be a superword MODE_PARTIAL_INT? (Our rules say "no".)
>
> It is needed for some processors, currently not officially supported.
> In the example above with the 20 bit addresses, some C++ address arithmetic
> is performed in SImode, and then at some stage this is converted to PSImode.
>
>> 3) What about things like 80-bit FP modes on a 32-bit or 64-bit target? Is it valid to refer to pieces of an 80-bit FP pseudo? If so, are the rules we've got here right?
>
> Where the 80-bit mode is stored in multiple words like for x86, you
> should be able to refer to word_mode subregs the way the value is
> stored in memory.  This is the only way you can get a sane equivalence
> between reloads via secondary memory and direct register-register
> moves invollving word_mode GENERAL_REGS.

OK, so in all these cases, "N words and a bit" modes can be treated
like "N + 1 words, with the upper bits undefined"?  For both inner
and outer modes?

>> 4) Do stores to subregs of hardreg invalidate just the registers
>> mentioned in the outer mode or do they invalidate the entire set of
>> registers mentioned in the inner mode? (our rules say only the outer
>> mode).
>
> Where the hardreg is actually a single hardware register, all of it is
> clobbered.  If it is a concatenation of multiple actual hard
> registers, the idea is that only the one that corresponds to the word
> that is stored into gets clobbered.  If more than one word is stored
> into, that would logically translate to changing each of the registers
> that each word corresponds to.
>
> What seems less defined is what happens when the underlying hard registers
> are smaller than a word, and either the mode size or SUBREG_BYTE
> is not a multiple of a word.

Yeah, my version of the question was more: do we support subregs of
hard registers in which the normal word-based semantics of pseudos
do not apply?  The current documentation expressly forbids taking
an SImode subreg of a DImode hard register on a 32-bit machine,
for example, and I agree that the subword hard register case is
also suspicious.

>> It is seldom necessary to wrap
>> hard registers in @code{subreg}s; such registers would normally
>> reduce to a single @code{reg} rtx.
>
> reload handling of matching operands of different size is broken for
> big endian, hence paradoxical subregs of hard registers are essential
> to express such matching operands.

Without wanting to fan flames, isn't this something that should
be fixed in reload? ;)  Reload is amenable to change...

Richard