Re: Fix to i386 binarry operation predicates

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Jan Hubicka wrote:

> *** i386.md     2002/02/09 17:53:58     1.334
> --- i386.md     2002/02/12 11:45:07
> ***************
> *** 13858,13867 ****
>   (define_insn "*fop_sf_comm_nosse"
>     [(set (match_operand:SF 0 "register_operand" "=f")
>         (match_operator:SF 3 "binary_fp_operator"
> !                       [(match_operand:SF 1 "register_operand" "%0")
>                          (match_operand:SF 2 "nonimmediate_operand" "fm")]))]
>     "TARGET_80387 && !TARGET_SSE_MATH
> !    && GET_RTX_CLASS (GET_CODE (operands[3])) == 'c'"
>     "* return output_387_binary_op (insn, operands);"
>     [(set (attr "type")
>         (if_then_else (match_operand:SF 3 "mult_operator" "")
> --- 13858,13868 ----
>   (define_insn "*fop_sf_comm_nosse"
>     [(set (match_operand:SF 0 "register_operand" "=f")
>         (match_operator:SF 3 "binary_fp_operator"
> !                       [(match_operand:SF 1 "nonimmediate_operand" "%0")
>                          (match_operand:SF 2 "nonimmediate_operand" "fm")]))]
>     "TARGET_80387 && !TARGET_SSE_MATH
> !    && GET_RTX_CLASS (GET_CODE (operands[3])) == 'c'
> !    && (GET_CODE (operands[1]) != MEM || GET_CODE (operands[2]) != MEM)"
>     "* return output_387_binary_op (insn, operands);"
>     [(set (attr "type")
>         (if_then_else (match_operand:SF 3 "mult_operator" "")

Hmmm, I get the idea that this patch causes the large differences in
SPECfp2000 figures (between 13/2 7:27 UTC and 13/2 15:54 UTC) as
produced by Andreas Jaeger's setup.

Unfortunately, it has positive and negative effects, e.g., applu that
drops 20+ points.

Could that be caused by the fact that operand constraints are now more
general and the conditional more restrictive, i.e., that sometimes this
instruction is chosen when it shouldn't be ?

Can this be tightened up, e.g., by Jan's own suggestion:

"Perhaps I can go with only single nonimmediate operand in the operand 1
 and rewrite predicates as "=f" "fm" "0", but I feel somewhat
 unconfortable about such reversed order isntructions."

?

Thanks for any insight offered.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)