long long / long long

[Hans-Peter Nilsson]

On Mon, 10 Sep 2001, Michael Matz wrote:
[About (non-)adjacency of register parts in a multi-word
register value]
> The sad thing is, that it _is_ easy to change in the allocator, and in
> fact would make the algorithm simpler (I'm talking only about the
> new-regalloc) and the graph easier colorable.  The thing which horrifies
> me is the encoding of that requirement in the different machine
> descriptions.  A first step would be to define a new rtx code MREG
> ("multi" reg), which can possibly contain a set of (disjoint) REG
> or SUBREG expressions, including the then necessary handling of multi-reg
> moves (with cycle breaking).  The occurences of those MREG rtx's could
> probably be limited to few passes around the allocator.  Unfortunately
> nevertheless all .md files would need a good overhaul.  If we only had
> such a multi-reg rtx from the beginning ;-|

Couldn't you use a PARALLEL for the multiword-parts there, so
you don't need to dream up a new rtx thingy?  Perhaps assuming
"natural" layout, (element 0 being the least significant for a
little-endian target etc.).  The PARALLEL would carry the size
of the composite mode, equal to the sum of all registers:
(set (mem:DI (reg:SI 0))
     (minus:DI (parallel:DI [(reg:SI 3) (reg:SI 7)])
               (const_int 1)))
or maybe just expand the semantics of CONCAT to hold more than
two items.

Alternatively the elements would carry subreg-byte indicators as
with the parallels for FUNCTION_ARG and FUNCTION_VALUE, so you
can carry smaller-than-register parts in multiple registers if
needed.

brgds, H-P