This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: long long / long long
- To: Michael Matz <matzmich at cs dot tu-berlin dot de>
- Subject: Re: long long / long long
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- Date: Mon, 10 Sep 2001 22:55:46 -0400 (EDT)
- cc: Bernd Schmidt <bernds at redhat dot com>, <gcc at gcc dot gnu dot org>
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