This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: MIPS patch (was Re: MEM tracking, round 3)
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: RFA: MIPS patch (was Re: MEM tracking, round 3)
- From: Richard Sandiford <r dot sandiford at redhat dot com>
- Date: 09 Jul 2001 16:57:28 +0100
- Cc: r dot sandiford at redhat dot com, gcc-patches at gcc dot gnu dot org
- References: <10107091540.AA05099@vlsi1.ultra.nyu.edu>
kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> Jeffrey Oldham already reported that this patch caused a problem on
> the MIPS. [...]
>
> No, I hadn't seen that report. What's the symptom here?
I meant <http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00245.html>. Like
I say, I don't know if it is the same problem or not.
> > *** config/mips/mips.c 2001/07/03 01:58:35 1.119
> > --- config/mips/mips.c 2001/07/03 14:07:21
> > *************** mips_move_2words (operands, insn)
> > *** 2539,2543 ****
> > else if (double_memory_operand (op1, GET_MODE (op1)))
> > {
> > ! operands[2] = adj_offsettable_operand (op1, 4);
> > ret = (reg_mentioned_p (op0, op1)
> > ? "lw\t%D0,%2\n\tlw\t%0,%1"
> > --- 2539,2543 ----
> > else if (double_memory_operand (op1, GET_MODE (op1)))
> > {
> > ! operands[2] = adjust_address (op1, SImode, 4);
> > ret = (reg_mentioned_p (op0, op1)
> > ? "lw\t%D0,%2\n\tlw\t%0,%1"
>
> I think that:
>
> operands[2] = adjust_address (op1, GET_MODE (op1), 4);
>
> would more accurately reflect what the old code did.
>
> I don't. The point is that the MEM is going to be used in an SImode
> context, namely the operand of an "lw" instruction. DImode is
> incorrect the address + 4 might not be valid and it would have to be
> to be used as DImode.
Yes, I agreee that describes the function of the MEM perfectly accurately.
But the old code didn't do what you describe. To requote from above,
it used to read:
operands[2] = adj_offsettable_operand (op1, 4);
which gave operands[2] the same mode as op1, i.e. a DImode or a DFmode.
As far as I can tell, operands[2] is a temporary created during assembly
output and the only purpose of creating it was to get something, of any
mode, that had the original address plus four.
> to get the address of the second word. That would make it easy to
> extend the '%D' prefix to MEMs with constant addresses, which would in
> turn remove the need for the dummy operand.
>
> I'm sorry, I don't follow.
I mean (from the patch I sent) it would be cleaner to make the following work:
*************** mips_move_2words (operands, insn)
*** 2552,2563 ****
}
else if (double_memory_operand (op1, GET_MODE (op1)))
! {
! operands[2] = adjust_address (op1, SImode, 4);
! ret = (reg_mentioned_p (op0, op1)
! ? "lw\t%D0,%2\n\tlw\t%0,%1"
! : "lw\t%0,%1\n\tlw\t%D0,%2");
! }
if (ret != 0 && MEM_VOLATILE_P (op1))
{
--- 2552,2560 ----
}
else if (double_memory_operand (op1, GET_MODE (op1)))
! ret = (reg_mentioned_p (op0, op1)
! ? "lw\t%D0,%D1\n\tlw\t%0,%1"
! : "lw\t%0,%1\n\tlw\t%D0,%D1");
if (ret != 0 && MEM_VOLATILE_P (op1))
{