state of 3.2.1-pre: how far from release?
Michael Matz
matz@suse.de
Wed Nov 6 04:01:00 GMT 2002
Hi,
On Tue, 5 Nov 2002, David Edelsohn wrote:
> On the GCC 3.2 branch, reload_as_needed() is entered with the
> instruction still containing pseudos.
This can't happen if there weren't bugs before reload:
> eliminate_regs_in_insn() substitutes a hard reg for the first use of
> the pseudo, but leaves the others untouched.
> eliminate_regs_in_insn() recognizes the instruction and
> recog_data.n_operands is 3, so it only loops over three locations.
> On the trunk, the instruction already has hard regs substituted when
> reload_as_needed() is called.
>
> Are pseudos suppose to be shared so that one substitution replaces
> all instances?
Yes, pseudo reg RTL _has_ to be shared. There needs to be exactly one
instance of (reg:MODE x) if x >= FIRST_PSEUDO_REGISTER, and it is placed
into regno_reg_rtx[x]. If there is a need to use a pseudo in a different
mode than MODE, you have to use subreg's.
> Shared within an instruction? The parallel is generated
> using:
>
> for (i = 0; i < count; i++)
> XVECEXP (operands[3], 0, i)
> = gen_rtx_SET (VOIDmode, gen_rtx_REG (SImode, regno + i),
> adjust_address (op1, SImode, i * 4));
Which rtx do contain the pseudos here? regno is a hard reg, right? So
does op1 contain pseudos?
> and adjust_address() calls copy_rtx() on the addr in the memref. Maybe
copy_rtx() applied to a pseudo reg rtx returns it, so copy_rtx() never
(should) create non-shared pseudos. The only way I currently remember is
to use gen_rtx_REG() on a pseudo reg number directly.
> the bug is calling adjust_address() to generate a sequence of memory
> addresses in a single instruction.
Ciao,
Michael.
More information about the Gcc
mailing list