This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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.

> 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.

The SH uses PSImode for the floating point control registyer because
only bits 20 and 19 - the size and precision bits - are handled like
ordinary data bits, while some other bits have to be preserved when
mode switching, and other bits are reserved.

> 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.

> 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.

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]