This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Your change of September 11, 1998
- To: rth at redhat dot com
- Subject: Re: Your change of September 11, 1998
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Mon, 15 Jan 01 19:10:34 EST
- Cc: gcc at gcc dot gnu dot org
I don't think there is any good documentation for this. :-(
At this point, I'd find *bad* documentation better than the current state ...
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.
Right.
Bernd has previously expressed a deep-seated loathing for that,
and thinks we ought to express this as a parallel of multiple sets.
This is an a CALL_INSN where SET_SRC is a CALL. If we have it as a
parellel of multiple sets, you first have the problem of where to put
the byte offsets, but you also have to do sharing of the CALL RTL, much
like the case of an ASM with multiple outputs. This seems like a mess.
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.
Right, but how do you recommend we fix this? The code in note_stores
is inconsistent with the rest and none of them handle the EXPR_LIST case,
as far as I can tell.