Hi Haochen,
Thanks for the patch, some comments are inlined.
on 2022/5/9 09:54, HAO CHEN GUI wrote:
> Hi,
> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> Tests show that outputs of xs[min/max]dp are consistent with the standard
> of C99 fmin/max.
>
> Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.
>
> ChangeLog
> 2022-05-09 Haochen Gui <guih...@linux.ibm.com>
>
> gcc/
> PR target/103605
> * rs6000.md (unspec): Add UNSPEC_FMAX and UNSPEC_FMIN.
Nit: one entry for iterator FMINMAX?
> (fminmax): New.
> (minmax_op): Likewise.
> (<fminmax><mode>3): New pattern. Implemented by UNSPEC_FMAX and
> UNSPEC_FMIN.
>
> gcc/testsuite/
> PR target/103605
> * gcc.dg/pr103605.c: New.
>
> patch.diff
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index fdfbc6566a5..8aae3e80bcd 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -158,6 +158,8 @@ (define_c_enum "unspec"
> UNSPEC_HASHCHK
> UNSPEC_XXSPLTIDP_CONST
> UNSPEC_XXSPLTIW_CONST
> + UNSPEC_FMAX
> + UNSPEC_FMIN
> ])
>
> ;;
> @@ -5350,6 +5352,25 @@ (define_insn_and_split "*s<minmax><mode>3_fpr"
> DONE;
> })
>
> +
> +(define_int_iterator FMINMAX [UNSPEC_FMAX UNSPEC_FMIN])
> +
> +(define_int_attr fminmax [(UNSPEC_FMAX "fmax")
> + (UNSPEC_FMIN "fmin")])
> +
> +(define_int_attr minmax_op [(UNSPEC_FMAX "max")
> + (UNSPEC_FMIN "min")])
> +
Can we use the later one for both?
Like f<minmax_op><mode>3.
> +(define_insn "<fminmax><mode>3"
> + [(set (match_operand:SFDF 0 "vsx_register_operand" "=<Fv>")
> + (unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "<Fv>")
> + (match_operand:SFDF 2 "vsx_register_operand" "<Fv>")]
Nit: both SD and DF are mapped to constraint wa, just hardcode Fv to wa?
> + FMINMAX))]
> +"TARGET_VSX"
> +"xs<minmax_op>dp %x0,%x1,%x2"
> +[(set_attr "type" "fp")]
> +)
Maybe it's good to put one comment before this pattern to note that
xs<minmax_op>
can satisfy all required semantics of fmin/fmax.
PR103605 also exposes another problem on bif __builtin_vsx_xs{min,max}dp, both
bifs are
expanded into xs{min,max}cdp instead of xs{min,max}dp starting from power9.
IMHO, it's something we want to fix as well, based on the reasons:
1) bif names have the corresponding mnemonics, users would expect 1-1 mapping
here.
2) clang emits xs{min,max}dp all the time, with cpu type power7/8/9/10.
3) according to uarch info, xs{min,max}cdp use the same units and have the
same latency,
no benefits to replace with xs{min,max}cdp.
So I wonder if it would be more clear with:
1) add new define_insn for xs{min,max}dp
2) use them for new define_expand of fmin/fmax
3) use them for bif expansion pattern
BR,
Kewen
> +
> (define_expand "mov<mode>cc"
> [(set (match_operand:GPR 0 "gpc_reg_operand")
> (if_then_else:GPR (match_operand 1 "comparison_operator")
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr103605.c
> b/gcc/testsuite/gcc.target/powerpc/pr103605.c
> new file mode 100644
> index 00000000000..a40da064742
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr103605.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_vsx_ok } */
> +/* { dg-options "-O1 -mvsx" } */
> +/* { dg-final { scan-assembler-times "xsmaxdp" 2 } } */
> +/* { dg-final { scan-assembler-times "xsmindp" 2 } } */
> +
> +#include <math.h>
> +
> +double test1 (double d0, double d1)
> +{
> + return fmin (d0, d1);
> +}
> +
> +float test2 (float d0, float d1)
> +{
> + return fmin (d0, d1);
> +}
> +
> +double test3 (double d0, double d1)
> +{
> + return fmax (d0, d1);
> +}
> +
> +float test4 (float d0, float d1)
> +{
> + return fmax (d0, d1);
> +}
>
