This is the mail archive of the
mailing list for the GCC project.
Re: Your change of September 11, 1998
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Subject: Re: Your change of September 11, 1998
- From: Richard Henderson <rth at redhat dot com>
- Date: Mon, 15 Jan 2001 14:18:51 -0800
- Cc: davem at redhat dot com, gcc at gcc dot gnu dot org
- References: <10101151711.AA23390@vlsi1.ultra.nyu.edu>
On Mon, Jan 15, 2001 at 12:10:25PM -0500, Richard Kenner wrote:
> I am very confused by that change. It appears to allow a PARALLEL as
> a SET_DEST. I don't see any documentation of the form of that PARALLEL.
I don't think there is any good documentation for this. :-(
The form was first introduced for MIPS quite some time ago as a
way to return a structure in multiple disjoint registers. Since
then it has been used on Sparc64, PA64 and IA-64, all of which
have non-trivial structure calling conventions.
> The code in note_stores, as best as I can see, expects each element to be a
> SET or CLOBBER, since it does ...
This had previously "worked" because this parallel form only appears
as the destination of a call, and contains only call-clobbered hard
regs. Thus for most applications, no one needed to know.
> However, in the Sparc 64 bit port, it's actually a PARALLEL where each
> entry is an EXPR_LIST, whose first expression is a register and whose
> second expression is a CONST_INT that appears to be a byte offset.
> What *is* the documentation of what's supposed to be there?
That is in fact that FUNCTION_VALUE or FUNCTION_ARG is supposed
to return. Whether that ought to make it into the call insn is
a deeper question that ought to be answered.
Bernd has previously expressed a deep-seated loathing for that,
and thinks we ought to express this as a parallel of multiple sets.
The current form has the advantage that a match_operand with no
predicate matches one of these constructs, and so we don't need
anything complicated in the .md file to handle them.