public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: acsawdey@linux.ibm.com
Cc: gcc-patches@gcc.gnu.org, wschmidt@linux.ibm.com, bergner@linux.ibm.com
Subject: Re: [PATCH,rs6000] Make MMA builtins use opaque modes
Date: Tue, 17 Nov 2020 16:42:22 -0600	[thread overview]
Message-ID: <20201117224222.GE2672@gate.crashing.org> (raw)
In-Reply-To: <20201117174804.2218917-1-acsawdey@linux.ibm.com>

Hi!

On Tue, Nov 17, 2020 at 11:48:04AM -0600, acsawdey@linux.ibm.com wrote:
> This patch changes powerpc MMA builtins to use the new opaque
> mode class and use modes OO (32 bytes) and XO (64 bytes)
> instead of POI/PXI. Using the opaque modes prevents
> optimization from trying to do anything with vector
> pair/quad, which was the problem we were seeing with the
> partial integer modes.

> 	* gcc/config/rs6000/mma.md (unspec):
> 	Add assemble/extract UNSPECs.

That fits on one line :-)  (More similar stuff below.)

> 	* gcc/config/rs6000/rs6000-modes.def: Create XO and OO modes.

You also delete OImode, XImode, POImode, and PXImode here.

> --- a/gcc/config/rs6000/mma.md
> +++ b/gcc/config/rs6000/mma.md
> @@ -19,24 +19,19 @@
>  ;; along with GCC; see the file COPYING3.  If not see
>  ;; <http://www.gnu.org/licenses/>.
>  
> -;; The MMA patterns use the multi-register PXImode and POImode partial
> +;; The MMA patterns use the multi-register XOmode and OOmode partial
>  ;; integer modes to implement the target specific __vector_quad and
>  ;; __vector_pair types that the MMA built-in functions reference.

They are opaque modes, not partial integer modes now :-)

> +;; We define these modes with the new OPAQUE_MODE mechanism to prevent
> +;; anything from trying to open them up.

Any time you write "new" it is dated soon.  Maybe just "these are
OPAQUE_MODEs" or similar?

> +(define_insn_and_split "*movxo"
> +  [(set (match_operand:XO 0 "nonimmediate_operand" "=d,m,d,d")
> +	(match_operand:XO 1 "input_operand" "m,d,d,O"))]
>    "TARGET_MMA
> +   && (gpc_reg_operand (operands[0], XOmode)
> +       || gpc_reg_operand (operands[1], XOmode))"
>    "@
>     #
>     #
>     #
>     xxsetaccz %A0"
>    "&& reload_completed
> +   && !(fpr_reg_operand (operands[0], XOmode) && operands[1] == const0_rtx)"

XOmode can never be a const_int anymore, so this should just be
  "&& reload_completed"
and nothing more.

Or do you need to handle the unspec case in here?  It can just be
handled in a separate pattern in this case, so that would be much
simpler.

> +(define_insn_and_split "*mma_assemble_pair"
> +  [(set (match_operand:OO 0 "vsx_register_operand" "=wa")
> +	(unspec:OO [(match_operand:V16QI 1 "mma_assemble_input_operand" "mwa")
> +		    (match_operand:V16QI 2 "mma_assemble_input_operand" "mwa")]
> +		    UNSPEC_MMA_ASSEMBLE))]
> +  "TARGET_MMA
> +   && vsx_register_operand (operands[0], OOmode)"

operands[0] always is an OOmode vsx_register_operand, so this is just
  "TARGET_MMA"

> +(define_insn_and_split "*mma_disassemble_pair"
> +  [(set (match_operand:V16QI 0 "mma_disassemble_output_operand" "=mwa")
> +       (unspec:V16QI [(match_operand:OO 1 "input_operand" "wa")
> +                      (match_operand 2 "const_int_operand")]
> +		      UNSPEC_MMA_EXTRACT))]

Use "const_0_to_1_operand" instead?

> +  "TARGET_MMA
> +   && fpr_reg_operand (operands[1], OOmode)"

But registers can be all in "wa", not just the FPRs?

> +  "#"
> +  "&& reload_completed"
> +  [(const_int 0)]
> +{
> +  gcc_assert (REG_P (operands[1]));

That is guaranteed by the insn condition.

> +  int reg = REGNO (operands[1]);
> +  int regoff = INTVAL (operands[2]);

Should this consider endianness?

> +  rtx src = gen_rtx_REG (V16QImode, reg + regoff);
> +  emit_move_insn (operands[0], src);
> +  DONE;
> +})


> +(define_expand "mma_disassemble_pair"

Please put the define_expand before the corresponding define_insn.

> +  [(match_operand:V16QI 0 "mma_disassemble_output_operand")
> +   (match_operand:OO 1 "input_operand")
> +   (match_operand 2 "const_int_operand")]

0_to_1 again

> +  "TARGET_MMA"
> +{
> +  rtx src;
> +  int regoff = INTVAL (operands[2]);
> +  gcc_assert (IN_RANGE (regoff, 0, 1));

This assert then trivially isn't needed anymore, either.

> +  src = gen_rtx_UNSPEC (V16QImode,
> +                        gen_rtvec (2, operands[1], GEN_INT (regoff)),
> +                        UNSPEC_MMA_EXTRACT);
> +  emit_move_insn (operands[0], src);
>    DONE;
>  })


> +(define_insn_and_split "*mma_disassemble_acc"
> +  [(set (match_operand:V16QI 0 "mma_disassemble_output_operand" "=mwa")
> +       (unspec:V16QI [(match_operand:XO 1 "input_operand" "d")
> +                      (match_operand 2 "const_int_operand")]

"const_0_to_3_operand", and everything else as well.

> +(define_expand "mma_disassemble_acc"

Also wrt this of course.

>  (define_expand "mma_xxsetaccz"
> -  [(set (match_operand:PXI 0 "fpr_reg_operand")
> +  [(set (match_operand:XO 0 "fpr_reg_operand")
>  	(const_int 0))]
>    "TARGET_MMA"
>  {
> -  emit_insn (gen_movpxi (operands[0], const0_rtx));
> +  emit_insn (gen_movxo (operands[0], const0_rtx));
>    DONE;
>  })

That should wrap the zero in an unspec?

> --- a/gcc/config/rs6000/predicates.md
> +++ b/gcc/config/rs6000/predicates.md
> @@ -1072,8 +1072,9 @@ (define_predicate "input_operand"
>        && easy_fp_constant (op, mode))
>      return 1;
>  
> -  /* Allow any integer constant.  */
> -  if (SCALAR_INT_MODE_P (mode) && CONST_SCALAR_INT_P (op))
> +  /* Allow any integer constant.  Also allow consts for OPAQUE_MODE.  */
> +  if ((SCALAR_INT_MODE_P (mode) || OPAQUE_MODE_P (mode))
> +      && CONST_SCALAR_INT_P (op))
>      return 1;

We shouln't allow constant integers as input to OPAQUE_MODE?  Such
things should be wrapped in an unspec.

> +;; Return 1 if this operand is valid for an MMA disassemble insn.
> +(define_predicate "mma_disassemble_output_operand"
> +  (match_code "reg,subreg,mem")
> +{
> +  if (REG_P (op) && !vsx_register_operand (op, mode))
> +    return false;
> +  return true;
> +})

You need to handle subreg here, even if you do not need to do anything
for mem.  So something like:

{
  if (SUBREG_P (op))
    op = SUBREG_REG (op);

  if (!REG_P (op))
    return 1;

  return vsx_register_operand (op);
}

> --- a/gcc/config/rs6000/rs6000-call.c
> +++ b/gcc/config/rs6000/rs6000-call.c
> @@ -6325,6 +6325,22 @@ rs6000_discover_homogeneous_aggregate (machine_mode mode, const_tree type,
>  bool
>  rs6000_return_in_memory (const_tree type, const_tree fntype ATTRIBUTE_UNUSED)
>  {
> +  /* We do not allow MMA types being used as return values.  Only report
> +     the invalid return value usage the first time we encounter it.  */
> +  if (cfun != NULL

You can just write "cfun" instead of "cfun != NULL", it looks much less
silly.

> +      && !cfun->machine->mma_return_type_error
> +      && TREE_TYPE (cfun->decl) == fntype
> +      && (TYPE_MODE (type) == OOmode || TYPE_MODE (type) == XOmode))
> +    {
> +      /* Record we have now handled function CFUN, so the next time we
> +	 are called, we do not re-report the same error.  */
> +      cfun->machine->mma_return_type_error = true;
> +      if (TYPE_CANONICAL (type) != NULL_TREE)
> +	type = TYPE_CANONICAL (type);
> +      error ("invalid use of MMA type %qs as a function return value",
> +	     IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))));
> +    }

Cool, thanks!

> @@ -14049,21 +14055,21 @@ mma_init_builtins (void)
>  	}
>        else
>  	{
> -	  if ((attr & RS6000_BTC_QUAD) == 0)
> +	  if ( !( d->code == MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL

Some stray spaces in there.

> +		  || d->code == MMA_BUILTIN_DISASSEMBLE_PAIR_INTERNAL)
> +	       && ((attr & RS6000_BTC_QUAD) == 0))

Get rid of some of the superfluous parens?  It makes it hard to read.

>  	}
>  
> -      if (icode == CODE_FOR_nothing)
> +      /* This is a disassemble pair/acc function. */
> +      if ( d->code == MMA_BUILTIN_DISASSEMBLE_ACC
> +	   || d->code == MMA_BUILTIN_DISASSEMBLE_PAIR)

Bad space (on both lines).

> --- a/gcc/config/rs6000/rs6000-modes.def
> +++ b/gcc/config/rs6000/rs6000-modes.def
> @@ -83,12 +83,6 @@ VECTOR_MODE (INT, SI, 2);     /*                 V2SI  */
>     combination.  */
>  PARTIAL_INT_MODE (TI, 128, PTI);
>  
> -/* Define, but don't use the larger integer modes.  We need an integer mode
> -   defined that is the same size as the vector pair and vector quad modes.  */
> -
> -INT_MODE (OI, 32);
> -INT_MODE (XI, 64);
> -
>  /* Modes used by __vector_pair and __vector_quad.  */
> -PARTIAL_INT_MODE (OI, 256, POI);	/* __vector_pair.  */
> -PARTIAL_INT_MODE (XI, 512, PXI);	/* __vector_quad.  */

Yay :-)

> +OPAQUE_MODE (OO, 32); /* instead of POI */
> +OPAQUE_MODE (XO, 64); /* instead of PXI */

Those comments already make no sense, because those types occur nowhere
anymore!  Just say what they *are* used for?  __vector_pair and
__vector_quad.

> @@ -16434,8 +16433,11 @@ rs6000_split_multireg_move (rtx dst, rtx src)
>        if (GET_CODE (src) == UNSPEC)
>  	{
>  	  gcc_assert (REG_P (dst)
> +		      && ((GET_MODE (src) == XOmode
> +			   && FP_REGNO_P (REGNO (dst)))
> +			  || (GET_MODE (src) == OOmode
> +			      && VSX_REGNO_P (REGNO (dst))))
> +		      && XINT (src, 1) == UNSPEC_MMA_ASSEMBLE);

You can write that as separate statements much more readable?

	  gcc_assert (XINT (src, 1) == UNSPEC_MMA_ASSEMBLE);
	  gcc_assert (REG_P (dst));
	  if (GET_MODE (src) == XOmode)
	    gcc_assert (FP_REGNO_P (REGNO (dst)));
	  if (GET_MODE (src) == OOmode)
	    gcc_assert (VSX_REGNO_P (REGNO (dst)));

> +	  if ( GET_MODE (src) == XOmode )

(stray spaces)

> +	    {
> +	      /* We are writing an accumulator register, so we have to
> +		 prime it after we've written it.  */
> +	      emit_insn (gen_mma_xxmtacc (dst, dst));
> +	    }

You don't need a block around single insns (and in GCC we do not usually
do that for comments either -- the comment should usually go before the
"if" anyway, like here :-) )


Lots of little stuff, but also a few more serious things.  Sorry :-)


Segher

  parent reply	other threads:[~2020-11-17 22:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 17:48 acsawdey
2020-11-17 18:41 ` Peter Bergner
2020-11-17 23:01   ` Segher Boessenkool
2020-11-17 23:24     ` Peter Bergner
2020-11-17 22:42 ` Segher Boessenkool [this message]
2020-11-19 18:58   ` [PATCH,rs6000] Make MMA builtins use opaque modes [v2] acsawdey
2020-11-19 20:08     ` Peter Bergner
2020-11-20  1:02     ` Aaron Sawdey
2020-11-20 19:10     ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201117224222.GE2672@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=acsawdey@linux.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=wschmidt@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).