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]
Other format: [Raw text]

RFA: RL78: Fix UMUL and $FP size


Hi DJ,

  I noticed a couple of RL78 patches in our local tree that ought to be
  upstream, so here they are.  The first is for the size of the frame
  pointer register and the second is for the UMUL instruction when both
  input operands are in the same register.

  OK to apply ?

Cheers
  Nick

gcc/ChangeLog
2014-01-29  Nick Clifton  <nickc@redhat.com>
	    DJ Delorie  <dj@redhat.com>

	* config/rl78/rl78.c (register_sizes): Make the "upper half" of
	%fp 2 to keep registers after it properly word-aligned.
	(rl78_alloc_physical_registers_umul): Handle the case where both
	input operands are the same.

Index: gcc/config/rl78/rl78.c
===================================================================
--- gcc/config/rl78/rl78.c	(revision 207224)
+++ gcc/config/rl78/rl78.c	(working copy)
@@ -327,13 +327,15 @@
 }
 
 /* Most registers are 8 bits.  Some are 16 bits because, for example,
-   gcc doesn't like dealing with $FP as a register pair.  This table
-   maps register numbers to size in bytes.  */
+   gcc doesn't like dealing with $FP as a register pair (the second
+   half of $fp is also 2 to keep reload happy wrt register pairs, but
+   no register class includes it).  This table maps register numbers
+   to size in bytes.  */
 static const int register_sizes[] =
 {
   1, 1, 1, 1, 1, 1, 1, 1,
   1, 1, 1, 1, 1, 1, 1, 1,
-  1, 1, 1, 1, 1, 1, 2, 1,
+  1, 1, 1, 1, 1, 1, 2, 2,
   1, 1, 1, 1, 1, 1, 1, 1,
   2, 2, 1, 1, 1
 };
@@ -2996,9 +2998,19 @@
 
   tmp_id = get_max_insn_count ();
   saved_op1 = OP (1);
-  
-  OP (1) = move_to_acc (1, insn);
 
+  if (rtx_equal_p (OP (1), OP (2)))
+    {
+      gcc_assert (GET_MODE (OP (2)) == QImode);
+      /* The MULU instruction does not support duplicate arguments
+	 but we know that if we copy OP (2) to X it will do so via
+	 A and thus OP (1) will already be loaded into A.  */
+      OP (2) = move_to_x (2, insn);
+      OP (1) = A;
+    }
+  else
+    OP (1) = move_to_acc (1, insn);
+
   MAYBE_OK (insn);
 
   /* If we omitted the move of OP1 into the accumulator (because


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