This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: state of 3.2.1-pre: how far from release?
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Geoff Keating <geoffk at geoffk dot org>, Richard Henderson <rth at redhat dot com>, Daniel Berlin <dan at dberlin dot org>, gcc at gcc dot gnu dot org
- Date: Wed, 06 Nov 2002 13:13:13 -0500
- Subject: Re: state of 3.2.1-pre: how far from release?
>>>>> Michael Matz writes:
Michael> Does the insn before eliminate_regs_in_insn() only contains refs to (reg
Michael> 929)? And is reg_renumber[929] smaller zero, but reg_equiv_constant[929]
Michael> is non-zero (and points to the rtl (plus:SI (reg r1) (const_int 520))? If
Michael> the answer to all these is yes, I think I know what happens, but not
Michael> exactly why.
Yes,
reg_renumber[929] = -1
and
reg_equiv_constant[929] = (plus:SI (reg r31) (const_int 520))
Michael> The content of substed_operand[] is placed back into the places of the
Michael> old operands, but according to the recog_data information. Because you
Michael> create that four-vector directly, and the matching insn pattern simply has
Michael> a (match_parallel) there, recog_data has no information about the other
Michael> operands, neither as normal operands, nor as (match_dup) like operands.
Michael> That's why the new rtl expression only is placed into the first operand
Michael> (for which there is a match_operand in the .md files).
All instances of (reg/f:SI 929) are shared. Why doesn't the
substition into the first operand affect all instances? Or, another way
of stating it, why doesn't the substitution overwrite the RTL at the
pointer instead of changing the pointer of the first operand, at least for
match_parallel?
David