Re: RFA: MIPS patch (was Re: MEM tracking, round 3)

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    Jeffrey Oldham already reported that this patch caused a problem on
    the MIPS.  I don't know if this is the same problem or not, but a
    reduced test case is:

	extern const long long d[];

	long long f () { return d[0]; }

No, I hadn't seen that report.  What's the symptom here?

    > *** 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.

    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.