Better handling for multi-word values?

Bernd Schmidt
Wed Sep 9 08:26:00 GMT 1998

On Tue, 8 Sep 1998, Richard Henderson wrote:

> On Mon, Sep 07, 1998 at 01:56:37PM -0600, Jeffrey A Law wrote:
> > So if concats where extended to handle multiple objects would we be
> > able to use them to do the same thing efficiently?
> > 
> > Or should CONCAT go away after your MULTIWORD changes?

I haven't really thought this far.  It's probably possible to handle
things with one rtx code, but there are some differences between CONCATs
and the MULTIWORDs I came up with.  CONCATs don't appear after rtl
generation, they can only hold two objects, and their subobjects are
not necessarily word-sized.  MULTIWORDs can appear later in the rtl
(but they don't have to, it's possible and likely to be desirable if they
are completely split up during rtl generation), they always contain
pseudo registers of word_mode, and they can hold a variable number of

> I'm not sure how much a thing like MULTIWORD buys us, at least
> in the context of the DImode bits being discussed here.  It's
> basically SUBREGs turned inside out, and would still require
> special code in combine and elsewhere to be able to deal with
> them effectively.
> I'm willing to be proven wrong, but my take on this issue is
> that we should just split up multi-word arithmetic entirely into
> its constituant parts right from the start, and just deal with
> plain ol' REGs.

That is the basic idea I had.  There is already code in optabs.c that knows
how to perform most operations on single words if the target does not have
the necessary multi-word patterns.  If a mechanism like MULTIWORD is
introduced, and patterns like iordi3 removed from a machine description,
this code will do its work.  The difference is that operand_subword no
longer gives it SUBREGs of DImode pseudos to work with, but gives it
SImode pseudos instead.


More information about the Gcc mailing list