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
