Hi Joern,
Thanks for the answer,
Joern Rennecke <[EMAIL PROTECTED]> 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
