This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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))
  	    {


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]