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