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: cmov optimizations



  In message <19980524141219.17978@twiddle.rth.home>you write:
  > 
  > --ReaqsoxgOBHFXBhH
  > Content-Type: text/plain; charset=us-ascii
  > 
  > I've noticed before that gcc does a remarkably pathetic job
  > of using conditional moves.  The main problem being that it
  > only considers using it for registers and constants.
:-0

I've noticed myself when I tried to use conditional moves with
complex conditions like:

;; A conditional move based on the output of a logical operation between
;; two registers.  Also store the value of the logical operation in a 
;; register.
(define_insn ""
  [(set (match_operand:SI 0 "register_operand" "=r,r,r,r,r,r,r,r")
	(if_then_else:SI
	 (match_operator 5 "logical_comparison_operator"
	    [(match_operator 6 "logical_operator"
	      [(match_operand:SI 3 "register_operand" "r,r,r,r,r,r,r,r")
	       (match_operand:SI 4 "register_operand" "r,r,r,r,r,r,r,r")])
	     (const_int 0)])
	 (match_operand:SI 1 "reg_or_cint_move_operand" "0,0,0,0,r,J,N,K")
	 (match_operand:SI 2 "reg_or_cint_move_operand" "r,J,N,K,0,0,0,0")))
   (set (match_operand:SI 7 "register_operand" "=&r,&r,&r,&r,&r,&r,&r,&r")
	(match_op_dup 6 [(match_dup 3) (match_dup 4)]))]
  ""
  "@
   %D6,%C5 %4,%3,%7\;copy %2,%0
   %D6,%C5 %4,%3,%7\;ldi %2,%0
   %D6,%C5 %4,%3,%7\;ldil L'%2,%0
   %D6,%C5 %4,%3,%7\;zdepi %Z2,%0
   %D6,%N5 %4,%3,%7\;copy %1,%0
   %D6,%N5 %4,%3,%7\;ldi %1,%0
   %D6,%N5 %4,%3,%7\;ldil L'%1,%0
   %D6,%N5 %4,%3,%7\;zdepi %Z1,%0"
  [(set_attr "type" "multi,multi,multi,nullshift,multi,multi,multi,nullshift")
   (set_attr "length" "8,8,8,8,8,8,8,8")])

This basically uses the general nullification facilities to eliminate branches
early in the compiler and create longer blocks (which is the primary benefit).

But generally we got worse code due to poor folding of the condition.  Hmm,
I wonder if it might be time to resurrect those changes now that we try
harder to fold the condition......


One of the other things what would be interesting would be to allow a
more complex operand1 or operand2.  They could be memory loads, shifts,
or any other single instruction on the PA.



  > 	* jump.c (rtx_unsafe_p): New function.
  > 	(jump_optimize): Use it on if/then/else transformations and
  > 	conditional move transformations.
Looks reasonable to me.

Jeff


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