PING^1 [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

["Kewen.Lin" <linkw@linux.ibm.com>]

Hi,

Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html

BR,
Kewen

on 2022/5/18 22:07, Kewen.Lin via Gcc-patches wrote:
> Hi,
> 
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions.  As shown in
> that PR, without one explicit mov optab on OOmode provided, it would
> call emit_move_insn recursively.
> 
> So this patch is to allow the mov pattern to be generated when we are
> expanding to RTL and have seen errors even without MMA supported, it's
> expected that the generated pattern would not cause further ICEs as the
> compilation would stop soon after expanding.
> 
> Bootstrapped and regtested on powerpc64-linux-gnu P8 and
> powerpc64le-linux-gnu P9 and P10.
> 
> v3: Update test case with dg-excess-errors.
> 
> v2: Polish some comments and add one test case as Will and Peter suggested.
>     https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592916.html
> 
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591150.html
> 
> Is it ok for trunk?
> 
> BR,
> Kewen
> -----
> 	PR target/103353
> 
> gcc/ChangeLog:
> 
> 	* config/rs6000/mma.md (define_expand movoo): Move TARGET_MMA condition
> 	check to preparation statements and add handlings for !TARGET_MMA.
> 	(define_expand movxo): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* gcc.target/powerpc/pr103353.c: New test.
> ---
>  gcc/config/rs6000/mma.md                    | 42 ++++++++++++++++++---
>  gcc/testsuite/gcc.target/powerpc/pr103353.c | 22 +++++++++++
>  2 files changed, 58 insertions(+), 6 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr103353.c
> 
> diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
> index 907c9d6d516..746a77a0957 100644
> --- a/gcc/config/rs6000/mma.md
> +++ b/gcc/config/rs6000/mma.md
> @@ -268,10 +268,25 @@ (define_int_attr avvi4i4i4	[(UNSPEC_MMA_PMXVI8GER4PP	"pmxvi8ger4pp")
>  (define_expand "movoo"
>    [(set (match_operand:OO 0 "nonimmediate_operand")
>  	(match_operand:OO 1 "input_operand"))]
> -  "TARGET_MMA"
> +  ""
>  {
> -  rs6000_emit_move (operands[0], operands[1], OOmode);
> -  DONE;
> +  if (TARGET_MMA) {
> +    rs6000_emit_move (operands[0], operands[1], OOmode);
> +    DONE;
> +  }
> +  /* Opaque modes are only expected to be available when MMA is supported,
> +     but PR103353 shows we may want to continue to expand a MMA built-in
> +     function, even if we have already emitted error messages about some
> +     missing required conditions.  As shown in that PR, without one
> +     explicit mov optab on OOmode provided, it would call emit_move_insn
> +     recursively.  So we allow this pattern to be generated when we are
> +     expanding to RTL and have seen errors, even though there is no MMA
> +     support.  It would not cause further ICEs as the compilation would
> +     stop soon after expanding.  */
> +  else if (currently_expanding_to_rtl && seen_error ())
> +    ;
> +  else
> +    gcc_unreachable ();
>  })
> 
>  (define_insn_and_split "*movoo"
> @@ -300,10 +315,25 @@ (define_insn_and_split "*movoo"
>  (define_expand "movxo"
>    [(set (match_operand:XO 0 "nonimmediate_operand")
>  	(match_operand:XO 1 "input_operand"))]
> -  "TARGET_MMA"
> +  ""
>  {
> -  rs6000_emit_move (operands[0], operands[1], XOmode);
> -  DONE;
> +  if (TARGET_MMA) {
> +    rs6000_emit_move (operands[0], operands[1], XOmode);
> +    DONE;
> +  }
> +  /* Opaque modes are only expected to be available when MMA is supported,
> +     but PR103353 shows we may want to continue to expand a MMA built-in
> +     function, even if we have already emitted error messages about some
> +     missing required conditions.  As shown in that PR, without one
> +     explicit mov optab on XOmode provided, it would call emit_move_insn
> +     recursively.  So we allow this pattern to be generated when we are
> +     expanding to RTL and have seen errors, even though there is no MMA
> +     support.  It would not cause further ICEs as the compilation would
> +     stop soon after expanding.  */
> +  else if (currently_expanding_to_rtl && seen_error ())
> +    ;
> +  else
> +    gcc_unreachable ();
>  })
> 
>  (define_insn_and_split "*movxo"
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr103353.c b/gcc/testsuite/gcc.target/powerpc/pr103353.c
> new file mode 100644
> index 00000000000..5d519fb1b7b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr103353.c
> @@ -0,0 +1,22 @@
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* If the default cpu type is power10 or later, MMA is enabled by default.
> +   To keep the test point available all the time, this case specifies
> +   -mdejagnu-cpu=power6 to make it be tested without MMA.  */
> +/* { dg-options "-maltivec -mdejagnu-cpu=power6" } */
> +
> +/* Verify there is no ICE and don't check the error messages on MMA
> +   requirement since they could be fragile and are not test points
> +   of this case.  */
> +/* { dg-excess-errors "pr103353" } */
> +
> +void
> +foo (__vector_pair *dst, double *x)
> +{
> +  dst[0] = __builtin_vsx_lxvp (0, (__vector_pair *)(void *)x);
> +}
> +
> +void
> +bar (__vector_pair *src, double *x)
> +{
> +  __builtin_vsx_stxvp (src[0], 0, (__vector_pair *)(void *)x);
> +}