This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: cmov optimizations
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: cmov optimizations
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 02 Jun 1998 22:43:02 -0600
- cc: egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
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