patch: ms1: decrement_and_branch* fixes

[Aldy Hernandez <aldyh at redhat dot com>]

Hullo.

The following patch fixes various problems with the 
decrement_and_branch_until_zero pattern.  First, it removes some
comments that no longer apply.  Second, it keys the instruction off
of a new TARGET_MS1_64_003, instead of the TARGET_MMUL.  And last,
it rewrites the pattern so it can handle reloads.

With this patch, newlib now builds for the MS1_64_003.

Applied to mainline.

	* config/ms1/ms1.h (TARGET_MS1_64_001): New.
	(TARGET_MS1_16_002): New.
	(TARGET_MS1_16_003): New.

	* config/ms1/ms1.md ("decrement_and_branch_until_zero"): Rewrite.
	("*decrement_and_branch_until_zero_no_clobber"): New.
	Add corresponding splitter for decrement_and_branch_until_zero
	instruction.
	Key all decrement_and_branch_until_zero patterns off of
	TARGET_MS1_16_003.

Index: config/ms1/ms1.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/ms1/ms1.h,v
retrieving revision 1.1
diff -c -p -r1.1 ms1.h
*** config/ms1/ms1.h	22 Aug 2005 16:12:14 -0000	1.1
--- config/ms1/ms1.h	26 Oct 2005 16:13:53 -0000
*************** march=MS1-16-003:exit-16-003.o%s} \
*** 86,91 ****
--- 86,95 ----
      }						\
    while (0)
  
+ #define TARGET_MS1_64_001 (ms1_cpu == PROCESSOR_MS1_64_001)
+ #define TARGET_MS1_16_002 (ms1_cpu == PROCESSOR_MS1_16_002)
+ #define TARGET_MS1_16_003 (ms1_cpu == PROCESSOR_MS1_16_003)
+ 
  #define TARGET_VERSION  fprintf (stderr, " (ms1)");
  
  #define OVERRIDE_OPTIONS ms1_override_options ()
Index: config/ms1/ms1.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/ms1/ms1.md,v
retrieving revision 1.3
diff -c -p -r1.3 ms1.md
*** config/ms1/ms1.md	30 Sep 2005 15:36:15 -0000	1.3
--- config/ms1/ms1.md	26 Oct 2005 16:13:53 -0000
***************
*** 68,101 ****
  		 [(eq_attr "type" "arith") (nil) (nil)])
  
  
- ;; Issue 64382
- ;; This pattern implements the decrement and branch non-zero instruction
- ;; which can be used by gcc loop optimizer under certain conditions.
- ;; For an example of it being used try compiling the gcc test case
- ;; gcc.c-torture/execute/921213-1.c with optimizations enabled.
- 
- ;; XXX - FIXME - TARGET_MUL is used as a condition since it is set when the
- ;; target is the MS1-16-003, which is the only Morpho CPU which currently
- ;; implements this instruction.  Strictly speaking we ought to define a
- ;; new command line switch to enable/disable the DBNZ instruction or else
- ;; change this pattern so that it explicitly checks for an MS1-16-003
- ;; architecture.
- 
  (define_insn "decrement_and_branch_until_zero"
!   [(parallel [(set (pc)
! 	           (if_then_else
! 	              (ne (match_operand:SI 0 "register_operand" "+r") (const_int 0))
! 	              (label_ref (match_operand 1 "" ""))
! 	              (pc)))
!               (set (match_dup 0)
! 	           (plus:SI (match_dup 0) (const_int -1)))
! 	     ])
!   ]
!   "TARGET_MUL"
    "dbnz\t%0, %l1%#"
    [(set_attr "length" "4")]
  )
  
  ;; This peephole is defined in the vain hope that it might actually trigger one
  ;; day, although I have yet to find a test case that matches it.  The normal
  ;; problem is that GCC likes to move the loading of the constant value -1 out
--- 68,133 ----
  		 [(eq_attr "type" "arith") (nil) (nil)])
  
  
  (define_insn "decrement_and_branch_until_zero"
!    [(set (pc)
! 	 (if_then_else
! 	  (ne (match_operand:SI 0 "nonimmediate_operand" "+r,*m")
! 	      (const_int 0))
! 	  (label_ref (match_operand 1 "" ""))
! 	  (pc)))
!     (set (match_dup 0)
! 	 (plus:SI (match_dup 0)
! 		  (const_int -1)))
!     (clobber (match_scratch:SI 2 "=X,r"))]
!   "TARGET_MS1_16_003"
!   "@
!    dbnz\t%0, %l1%#
!    #"
!   [(set_attr "length" "4,16")]
! )
! 
! ;; Same as above, but without the clobber. The peephole below will
! ;; match this pattern.
! (define_insn "*decrement_and_branch_until_zero_no_clobber"
!    [(set (pc)
! 	 (if_then_else
! 	  (ne (match_operand:SI 0 "register_operand" "+r")
! 	      (const_int 0))
! 	  (label_ref (match_operand 1 "" ""))
! 	  (pc)))
!     (set (match_dup 0)
! 	 (plus:SI (match_dup 0)
! 		  (const_int -1)))]
!   "TARGET_MS1_16_003"
    "dbnz\t%0, %l1%#"
    [(set_attr "length" "4")]
  )
  
+ ;; Split the above to handle the case where operand 0 is in memory
+ ;; (a register that couldn't get a hard register).
+ (define_split
+   [(set (pc)
+ 	(if_then_else
+ 	  (ne (match_operand:SI 0 "memory_operand" "")
+ 	      (const_int 0))
+ 	  (label_ref (match_operand 1 "" ""))
+ 	  (pc)))
+     (set (match_dup 0)
+ 	 (plus:SI (match_dup 0)
+ 		  (const_int -1)))
+     (clobber (match_scratch:SI 2 ""))]
+   "TARGET_MS1_16_003"
+   [(set (match_dup 2) (match_dup 0))
+    (set (match_dup 2) (plus:SI (match_dup 2) (const_int -1)))
+    (set (match_dup 0) (match_dup 2))
+    (set (pc)
+ 	(if_then_else
+ 	 (ne (match_dup 2)
+ 	     (const_int 0))
+ 	 (label_ref (match_dup 1))
+ 	 (pc)))]
+   "")
+ 
  ;; This peephole is defined in the vain hope that it might actually trigger one
  ;; day, although I have yet to find a test case that matches it.  The normal
  ;; problem is that GCC likes to move the loading of the constant value -1 out
***************
*** 111,117 ****
  		(label_ref (match_operand 2 "" ""))
  		(pc)))
     ]
!   "TARGET_MUL"
    [(parallel [(set (pc)
  	           (if_then_else
  	              (ne (match_dup 0) (const_int 0))
--- 143,149 ----
  		(label_ref (match_operand 2 "" ""))
  		(pc)))
     ]
!   "TARGET_MS1_16_003"
    [(parallel [(set (pc)
  	           (if_then_else
  	              (ne (match_dup 0) (const_int 0))