public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Meissner <meissner@linux.ibm.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches@gcc.gnu.org,
	Segher Boessenkool <segher@kernel.crashing.org>,
	David Edelsohn <dje.gcc@gmail.com>,
	Peter Bergner <bergner@linux.ibm.com>
Subject: Re: Repost [PATCH 3/6] PowerPC: Add support for accumulators in DMR registers.
Date: Tue, 6 Feb 2024 19:06:33 -0500	[thread overview]
Message-ID: <ZcLJiTZW0d2Ys3V7@cowardly-lion.the-meissners.org> (raw)
In-Reply-To: <d40688c4-42db-7df6-3b64-84ce28a992de@linux.ibm.com>

On Thu, Jan 25, 2024 at 05:28:49PM +0800, Kewen.Lin wrote:
> Hi Mike,
> 
> on 2024/1/6 07:38, Michael Meissner wrote:
> > The MMA subsystem added the notion of accumulator registers as an optional
> > feature of ISA 3.1 (power10).  In ISA 3.1, these accumulators overlapped with
> > the traditional floating point registers 0..31, but logically the accumulator
> > registers were separate from the FPR registers.  In ISA 3.1, it was anticipated
> 
> Using VSX register 0..31 rather than traditional floating point registers 0..31
> seems more clear, since floating point registers imply 64 bit long registers.

Ok.

> > that in future systems, the accumulator registers may no overlap with the FPR
> > registers.  This patch adds the support for dense math registers as separate
> > registers.
> > 
> > This particular patch does not change the MMA support to use the accumulators
> > within the dense math registers.  This patch just adds the basic support for
> > having separate DMRs.  The next patch will switch the MMA support to use the
> > accumulators if -mcpu=future is used.
> > 
> > For testing purposes, I added an undocumented option '-mdense-math' to enable
> > or disable the dense math support.
> 
> Can we avoid this and use one macro for it instead?  As you might have noticed
> that some previous temporary options like -mpower{8,9}-vector cause ICEs due to
> some unexpected combination and we are going to neuter them, so let's try our
> best to avoid it if possible.  I guess one macro TARGET_DENSE_MATH defined by
> TARGET_FUTURE && TARGET_MMA matches all use places? and specifying -mcpu=future
> can enable it while -mcpu=power10 can disable it.

That depends on whether there will be other things added in the future power
that are not in the MMA+ instruction set.

But I can switch to defining TARGET_DENSE_MATH to testing TARGET_FUTURE and
TARGET_MMA.  That way if/when a new cpu comes out, we will just have to change
the definition of TARGET_DENSE_MATH and not all of the uses.

I will also add TARGET_MMA_NO_DENSE_MATH to handle the existing MMA code for
assemble and disassemble when we don't have dense math instructions.

> > 
> > This patch adds a new constraint (wD).  If MMA is selected but dense math is
> > not selected (i.e. -mcpu=power10), the wD constraint will allow access to
> > accumulators that overlap with the VSX vector registers 0..31.  If both MMA and
> 
> Sorry for nitpicking, it's more accurate with "VSX registers 0..31".

Ok.

> > diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
> > index c99997bf82b..614e431c085 100644
> > --- a/gcc/config/rs6000/constraints.md
> > +++ b/gcc/config/rs6000/constraints.md
> > @@ -107,6 +107,9 @@ (define_constraint "wB"
> >         (match_test "TARGET_P8_VECTOR")
> >         (match_operand 0 "s5bit_cint_operand")))
> >  
> > +(define_register_constraint "wD" "rs6000_constraints[RS6000_CONSTRAINT_wD]"
> > +  "Accumulator register.")
> > +
> >  (define_constraint "wE"
> >    "@internal Vector constant that can be loaded with the XXSPLTIB instruction."
> >    (match_test "xxspltib_constant_nosplit (op, mode)"))
> > diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md
> > index 6a7d8a836db..bb898919ab5 100644
> > --- a/gcc/config/rs6000/mma.md
> > +++ b/gcc/config/rs6000/mma.md
> > @@ -91,6 +91,7 @@ (define_c_enum "unspec"
> >     UNSPEC_MMA_XVI8GER4SPP
> >     UNSPEC_MMA_XXMFACC
> >     UNSPEC_MMA_XXMTACC
> > +   UNSPEC_DM_ASSEMBLE_ACC
> 
> The other UNSPEC.*ASSEMBLE like UNSPECV_MMA_ASSEMBLE don't have _ACC suffix,
> it's better to keep consistent if this suffix doesn't distinguish something.

Ok.

> >    ])
> >  
> >  (define_c_enum "unspecv"
> > @@ -321,7 +322,9 @@ (define_insn_and_split "*movoo"
> >     (set_attr "length" "*,8,*,8,8")
> >     (set_attr "isa" "lxvp,*,stxvp,*,*")])
> >  \f
> > -;; Vector quad support.  XOmode can only live in FPRs.
> > +;; Vector quad support.  Under the original MMA, XOmode can only live in VSX
> > +;; vector registers 0..31.  With dense math, XOmode can live in either VSX
> 
> Nit: s/vector//

Ok.

> > +;; registers (0..63) or DMR registers.
> >  (define_expand "movxo"
> >    [(set (match_operand:XO 0 "nonimmediate_operand")
> >  	(match_operand:XO 1 "input_operand"))]
> > @@ -346,10 +349,10 @@ (define_expand "movxo"
> >      gcc_assert (false);
> >  })
> >  
> > -(define_insn_and_split "*movxo"
> > +(define_insn_and_split "*movxo_nodm"
> >    [(set (match_operand:XO 0 "nonimmediate_operand" "=d,ZwO,d")
> >  	(match_operand:XO 1 "input_operand" "ZwO,d,d"))]
> > -  "TARGET_MMA
> > +  "TARGET_MMA && !TARGET_DENSE_MATH
> >     && (gpc_reg_operand (operands[0], XOmode)
> >         || gpc_reg_operand (operands[1], XOmode))"
> >    "@
> > @@ -366,6 +369,31 @@ (define_insn_and_split "*movxo"
> >     (set_attr "length" "*,*,16")
> >     (set_attr "max_prefixed_insns" "2,2,*")])
> >  
> > +(define_insn_and_split "*movxo_dm"
> > +  [(set (match_operand:XO 0 "nonimmediate_operand" "=wa,QwO,wa,wD,wD,wa")
> > +	(match_operand:XO 1 "input_operand"        "QwO,wa, wa,wa,wD,wD"))]
> 
> Why not adopt ZwO rather than QwO?

You have to split the address into 2 addresses for loading or storing vector
pairs (or 4 addresses for loading or storing vectors).  Z would allow
register+register addresses, and you wouldn't be able to create the second 
address by adding 128 to it.  Hence it uses 'Q' for register only and 'wo' for
d-form addresses.

> 
> > +  "TARGET_DENSE_MATH
> > +   && (gpc_reg_operand (operands[0], XOmode)
> > +       || gpc_reg_operand (operands[1], XOmode))"
> > +  "@
> > +   #
> > +   #
> > +   #
> > +   dmxxinstdmr512 %0,%1,%Y1,0
> > +   dmmr %0,%1
> > +   dmxxextfdmr512 %0,%Y0,%1,0"
> > +  "&& reload_completed
> > +   && !dmr_operand (operands[0], XOmode)
> > +   && !dmr_operand (operands[1], XOmode)"
> > +  [(const_int 0)]
> > +{
> > +  rs6000_split_multireg_move (operands[0], operands[1]);
> > +  DONE;
> > +}
> > +  [(set_attr "type" "vecload,vecstore,veclogical,mma,mma,mma")
> > +   (set_attr "length" "*,*,16,*,*,*")
> > +   (set_attr "max_prefixed_insns" "2,2,*,*,*,*")])
> > +
> >  (define_expand "vsx_assemble_pair"
> >    [(match_operand:OO 0 "vsx_register_operand")
> >     (match_operand:V16QI 1 "mma_assemble_input_operand")
> > @@ -433,25 +461,38 @@ (define_insn_and_split "*vsx_disassemble_pair"
> >  })
> >  
> >  (define_expand "mma_assemble_acc"
> > -  [(match_operand:XO 0 "fpr_reg_operand")
> > +  [(match_operand:XO 0 "register_operand")
> 
> Maybe use the newly introduced accumulator_operand?

Ok.

> 
> >     (match_operand:V16QI 1 "mma_assemble_input_operand")
> >     (match_operand:V16QI 2 "mma_assemble_input_operand")
> >     (match_operand:V16QI 3 "mma_assemble_input_operand")
> >     (match_operand:V16QI 4 "mma_assemble_input_operand")]
> >    "TARGET_MMA"
> >  {
> > -  rtx src = gen_rtx_UNSPEC_VOLATILE (XOmode,
> > -			    	     gen_rtvec (4, operands[1], operands[2],
> > -				       		operands[3], operands[4]),
> > -			    	     UNSPECV_MMA_ASSEMBLE);
> > -  emit_move_insn (operands[0], src);
> > +  rtx op0 = operands[0];
> > +  rtx op1 = operands[1];
> > +  rtx op2 = operands[2];
> > +  rtx op3 = operands[3];
> > +  rtx op4 = operands[4];
> > +
> > +  if (TARGET_DENSE_MATH)
> > +    {
> > +      rtx vpair1 = gen_reg_rtx (OOmode);
> > +      rtx vpair2 = gen_reg_rtx (OOmode);
> > +      emit_insn (gen_vsx_assemble_pair (vpair1, op1, op2));
> > +      emit_insn (gen_vsx_assemble_pair (vpair2, op3, op4));
> > +      emit_insn (gen_mma_assemble_acc_dm (op0, vpair1, vpair2));
> > +    }
> > +
> > +  else
> > +    emit_insn (gen_mma_assemble_acc_vsx (op0, op1, op2, op3, op4));
> > +
> >    DONE;
> >  })
> >  
> >  ;; We cannot update the four output registers atomically, so mark the output
> > -;; as an early clobber so we don't accidentally clobber the input operands.  */
> > +;; as an early clobber so we don't accidentally clobber the input operands.
> >  
> > -(define_insn_and_split "*mma_assemble_acc"
> > +(define_insn_and_split "mma_assemble_acc_vsx"
> 
> Nit: since we use "*_nodm" above, it seems better to name it with
> "mma_assemble_acc_nodm" which has the same style?

Ok.

> >    [(set (match_operand:XO 0 "fpr_reg_operand" "=&d")
> >  	(unspec_volatile:XO
> >  	  [(match_operand:V16QI 1 "mma_assemble_input_operand" "mwa")
> > @@ -459,7 +500,7 @@ (define_insn_and_split "*mma_assemble_acc"
> >  	   (match_operand:V16QI 3 "mma_assemble_input_operand" "mwa")
> >  	   (match_operand:V16QI 4 "mma_assemble_input_operand" "mwa")]
> >  	  UNSPECV_MMA_ASSEMBLE))]
> > -  "TARGET_MMA
> > +  "TARGET_MMA && !TARGET_DENSE_MATH
> >     && fpr_reg_operand (operands[0], XOmode)"
> >    "#"
> >    "&& reload_completed"
> > @@ -473,28 +514,31 @@ (define_insn_and_split "*mma_assemble_acc"
> >    DONE;
> >  })
> >  
> > +;; On a system with dense math, we build the accumulators from two vector
> > +;; pairs.
> > +
> > +(define_insn "mma_assemble_acc_dm"
> > + [(set (match_operand:XO 0 "dmr_operand" "=wD")
> > +       (unspec:XO [(match_operand:OO 1 "vsx_register_operand" "wa")
> > +		   (match_operand:OO 2 "vsx_register_operand" "wa")]
> > +		  UNSPEC_DM_ASSEMBLE_ACC))]
> > + "TARGET_MMA && TARGET_DENSE_MATH"
> 
> Nit: redundant TARGET_MMA checking.

Ok.

> > + "dmxxinstdmr512 %0,%1,%2,0"
> > + [(set_attr "type" "mma")])
> > +
> >  (define_expand "mma_disassemble_acc"
> > -  [(match_operand:V16QI 0 "mma_disassemble_output_operand")
> > -   (match_operand:XO 1 "fpr_reg_operand")
> > -   (match_operand 2 "const_0_to_3_operand")]
> > -  "TARGET_MMA"
> > -{
> > -  rtx src;
> > -  int regoff = INTVAL (operands[2]);
> > -  src = gen_rtx_UNSPEC (V16QImode,
> > -			gen_rtvec (2, operands[1], GEN_INT (regoff)),
> > -			UNSPEC_MMA_EXTRACT);
> > -  emit_move_insn (operands[0], src);
> > -  DONE;
> > -})
> > +  [(set (match_operand:V16QI 0 "register_operand")
> > +	(unspec:V16QI [(match_operand:XO 1 "register_operand")
> 
> s/register_operand/accumulator_operand/?

Ok

> 
> > +		       (match_operand 2 "const_0_to_3_operand")]
> > +		      UNSPEC_MMA_EXTRACT))]
> > +  "TARGET_MMA")
> >  
> > -(define_insn_and_split "*mma_disassemble_acc"
> > +(define_insn_and_split "*mma_disassemble_acc_vsx"
> >    [(set (match_operand:V16QI 0 "mma_disassemble_output_operand" "=mwa")
> > -       (unspec:V16QI [(match_operand:XO 1 "fpr_reg_operand" "d")
> > -		      (match_operand 2 "const_0_to_3_operand")]
> > +	(unspec:V16QI [(match_operand:XO 1 "fpr_reg_operand" "d")
> > +		       (match_operand 2 "const_0_to_3_operand")]
> >  		      UNSPEC_MMA_EXTRACT))]
> > -  "TARGET_MMA
> > -   && fpr_reg_operand (operands[1], XOmode)"
> > +  "TARGET_MMA"
> 
> Do we still expect to see this pattern if TARGET_DENSE_MATH?
> If no, we should guard the condition with !TARGET_DENSE_MATH.

Ok.
> 
> >    "#"
> >    "&& reload_completed"
> >    [(const_int 0)]
> > @@ -506,9 +550,14 @@ (define_insn_and_split "*mma_disassemble_acc"
> >    DONE;
> >  })
> >  
> > -;; MMA instructions that do not use their accumulators as an input, still
> > -;; must not allow their vector operands to overlap the registers used by
> > -;; the accumulator.  We enforce this by marking the output as early clobber.
> > +(define_insn "*mma_disassemble_acc_dm"
> > +  [(set (match_operand:V16QI 0 "vsx_register_operand" "=wa")
> > +	(unspec:V16QI [(match_operand:XO 1 "dmr_operand" "wD")
> > +		       (match_operand 2 "const_0_to_3_operand")]
> > +		      UNSPEC_MMA_EXTRACT))]
> > +  "TARGET_DENSE_MATH"
> > +  "dmxxextfdmr256 %0,%1,2"
> > +  [(set_attr "type" "mma")])
> >  
> >  (define_insn "mma_<acc>"
> >    [(set (match_operand:XO 0 "fpr_reg_operand" "=&d")
> > diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
> > index d23ce9a77a3..3040dcd50a3 100644
> > --- a/gcc/config/rs6000/predicates.md
> > +++ b/gcc/config/rs6000/predicates.md
> > @@ -186,6 +186,38 @@ (define_predicate "vlogical_operand"
> >    return VLOGICAL_REGNO_P (REGNO (op));
> >  })
> >  
> > +;; Return 1 if op is a DMR register
> > +(define_predicate "dmr_operand"
> > +  (match_operand 0 "register_operand")
> > +{
> > +  if (!REG_P (op))
> > +    return 0;
> > +
> > +  if (!HARD_REGISTER_P (op))
> > +    return 1;
> > +
> > +  return DMR_REGNO_P (REGNO (op));
> > +})
> > +
> > +;; Return 1 if op is an accumulator.  On power10 systems, the accumulators
> > +;; overlap with the FPRs, while on systems with dense math, the accumulators
> > +;; are separate dense math registers and do not overlap with the FPR
> > +;; registers..
> 
> Nit: an unexpected "."?
> 
> > +(define_predicate "accumulator_operand"
> > +  (match_operand 0 "register_operand")
> > +{
> 
> fpr_reg_operand checks for subreg as well, should we check for it here as well?
> 
> > +  if (!REG_P (op))
> > +    return 0;
> > +
> > +  if (!HARD_REGISTER_P (op))
> > +    return 1;
> > +
> > +  int r = REGNO (op);
> > +  return (TARGET_DENSE_MATH
> > +	  ? DMR_REGNO_P (r)
> > +	  : FP_REGNO_P (r) && (r & 3) == 0);
> > +})
> > +
> >  ;; Return 1 if op is the carry register.
> >  (define_predicate "ca_operand"
> >    (match_operand 0 "register_operand")
> > diff --git a/gcc/config/rs6000/rs6000-cpus.def b/gcc/config/rs6000/rs6000-cpus.def
> > index b6cd6d8cc84..4621b97b522 100644
> > --- a/gcc/config/rs6000/rs6000-cpus.def
> > +++ b/gcc/config/rs6000/rs6000-cpus.def
> > @@ -91,6 +91,7 @@
> >  /* Flags for a potential future processor that may or may not be delivered.  */
> >  #define ISA_FUTURE_MASKS	(ISA_3_1_MASKS_SERVER			\
> >  				 | OPTION_MASK_BLOCK_OPS_VECTOR_PAIR	\
> > +				 | OPTION_MASK_DENSE_MATH		\
> >  				 | OPTION_MASK_FUTURE)
> >  
> >  /* Flags that need to be turned off if -mno-power9-vector.  */
> > @@ -134,6 +135,7 @@
> >  				 | OPTION_MASK_DFP			\
> >  				 | OPTION_MASK_DIRECT_MOVE		\
> >  				 | OPTION_MASK_DLMZB			\
> > +				 | OPTION_MASK_DENSE_MATH		\
> >  				 | OPTION_MASK_EFFICIENT_UNALIGNED_VSX	\
> >  				 | OPTION_MASK_FLOAT128_HW		\
> >  				 | OPTION_MASK_FLOAT128_KEYWORD		\
> > diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> > index bc509399cf6..83e32f7a43a 100644
> > --- a/gcc/config/rs6000/rs6000.cc
> > +++ b/gcc/config/rs6000/rs6000.cc
> > @@ -290,7 +290,8 @@ enum rs6000_reg_type {
> >    ALTIVEC_REG_TYPE,
> >    FPR_REG_TYPE,
> >    SPR_REG_TYPE,
> > -  CR_REG_TYPE
> > +  CR_REG_TYPE,
> > +  DMR_REG_TYPE
> >  };
> >  
> >  /* Map register class to register type.  */
> > @@ -304,22 +305,23 @@ static enum rs6000_reg_type reg_class_to_reg_type[N_REG_CLASSES];
> >  
> >  
> >  /* Register classes we care about in secondary reload or go if legitimate
> > -   address.  We only need to worry about GPR, FPR, and Altivec registers here,
> > -   along an ANY field that is the OR of the 3 register classes.  */
> > +   address.  We only need to worry about GPR, FPR, Altivec, and DMR registers
> > +   here, along an ANY field that is the OR of the 4 register classes.  */
> >  
> >  enum rs6000_reload_reg_type {
> >    RELOAD_REG_GPR,			/* General purpose registers.  */
> >    RELOAD_REG_FPR,			/* Traditional floating point regs.  */
> >    RELOAD_REG_VMX,			/* Altivec (VMX) registers.  */
> > -  RELOAD_REG_ANY,			/* OR of GPR, FPR, Altivec masks.  */
> > +  RELOAD_REG_DMR,			/* DMR registers.  */
> > +  RELOAD_REG_ANY,			/* OR of GPR/FPR/VMX/DMR masks.  */
> >    N_RELOAD_REG
> >  };
> >  
> > -/* For setting up register classes, loop through the 3 register classes mapping
> > +/* For setting up register classes, loop through the 4 register classes mapping
> >     into real registers, and skip the ANY class, which is just an OR of the
> >     bits.  */
> >  #define FIRST_RELOAD_REG_CLASS	RELOAD_REG_GPR
> > -#define LAST_RELOAD_REG_CLASS	RELOAD_REG_VMX
> > +#define LAST_RELOAD_REG_CLASS	RELOAD_REG_DMR
> >  
> >  /* Map reload register type to a register in the register class.  */
> >  struct reload_reg_map_type {
> > @@ -331,6 +333,7 @@ static const struct reload_reg_map_type reload_reg_map[N_RELOAD_REG] = {
> >    { "Gpr",	FIRST_GPR_REGNO },	/* RELOAD_REG_GPR.  */
> >    { "Fpr",	FIRST_FPR_REGNO },	/* RELOAD_REG_FPR.  */
> >    { "VMX",	FIRST_ALTIVEC_REGNO },	/* RELOAD_REG_VMX.  */
> > +  { "DMR",	FIRST_DMR_REGNO },	/* RELOAD_REG_DMR.  */
> >    { "Any",	-1 },			/* RELOAD_REG_ANY.  */
> >  };
> >  
> > @@ -1224,6 +1227,8 @@ char rs6000_reg_names[][8] =
> >        "0",  "1",  "2",  "3",  "4",  "5",  "6",  "7",
> >    /* vrsave vscr sfp */
> >        "vrsave", "vscr", "sfp",
> > +  /* DMRs */
> > +      "0", "1", "2", "3", "4", "5", "6", "7",
> >  };
> >  
> >  #ifdef TARGET_REGNAMES
> > @@ -1250,6 +1255,8 @@ static const char alt_reg_names[][8] =
> >    "%cr0",  "%cr1", "%cr2", "%cr3", "%cr4", "%cr5", "%cr6", "%cr7",
> >    /* vrsave vscr sfp */
> >    "vrsave", "vscr", "sfp",
> > +  /* DMRs */
> > +  "%dmr0", "%dmr1", "%dmr2", "%dmr3", "%dmr4", "%dmr5", "%dmr6", "%dmr7",
> 
> Should be without "r" here, as tested gas doesn't recognize %dmr0 but it does
> recognize %dm0.
> 
> >  };
> >  #endif
> >  
> > @@ -1846,6 +1853,9 @@ rs6000_hard_regno_nregs_internal (int regno, machine_mode mode)
> >    else if (ALTIVEC_REGNO_P (regno))
> >      reg_size = UNITS_PER_ALTIVEC_WORD;
> >  
> > +  else if (DMR_REGNO_P (regno))
> > +    reg_size = UNITS_PER_DMR_WORD;
> > +
> >    else
> >      reg_size = UNITS_PER_WORD;
> >  
> > @@ -1867,9 +1877,36 @@ rs6000_hard_regno_mode_ok_uncached (int regno, machine_mode mode)
> >    if (mode == OOmode)
> >      return (TARGET_MMA && VSX_REGNO_P (regno) && (regno & 1) == 0);
> >  
> > -  /* MMA accumulator modes need FPR registers divisible by 4.  */
> > +  /* On ISA 3.1 (power10), MMA accumulator modes need FPR registers divisible
> > +     by 4.
> > +
> > +     If dense math is enabled, allow all VSX registers plus the DMR registers.
> > +     We need to make sure we don't cross between the boundary of FPRs and
> > +     traditional Altiviec registers.  */
> >    if (mode == XOmode)
> > -    return (TARGET_MMA && FP_REGNO_P (regno) && (regno & 3) == 0);
> > +    {
> > +      if (TARGET_MMA && !TARGET_DENSE_MATH)
> > +	return (FP_REGNO_P (regno) && (regno & 3) == 0);
> > +
> > +      else if (TARGET_DENSE_MATH)
> > +	{
> > +	  if (DMR_REGNO_P (regno))
> > +	    return 1;
> > +
> > +	  if (FP_REGNO_P (regno))
> > +	    return ((regno & 1) == 0 && regno <= LAST_FPR_REGNO - 3);
> > +
> > +	  if (ALTIVEC_REGNO_P (regno))
> > +	    return ((regno & 1) == 0 && regno <= LAST_ALTIVEC_REGNO - 3);
> > +	}
> 
> I could miss something, I didn't find which section of RFC indicates this
> restriction, could you please point out for me?  Thanks!
> 
> > +
> > +      else
> > +	return 0;
> > +    }
> > +
> > +  /* No other types other than XOmode can go in DMRs.  */
> > +  if (DMR_REGNO_P (regno))
> > +    return 0;
> >  
> >    /* PTImode can only go in GPRs.  Quad word memory operations require even/odd
> >       register combinations, and use PTImode where we need to deal with quad
> > @@ -2312,6 +2349,7 @@ rs6000_debug_reg_global (void)
> >    rs6000_debug_reg_print (FIRST_ALTIVEC_REGNO,
> >  			  LAST_ALTIVEC_REGNO,
> >  			  "vs");
> > +  rs6000_debug_reg_print (FIRST_DMR_REGNO, LAST_DMR_REGNO, "dmr");
> 
> Nit: Like above, use 'dm'.
> 
> >    rs6000_debug_reg_print (LR_REGNO, LR_REGNO, "lr");
> >    rs6000_debug_reg_print (CTR_REGNO, CTR_REGNO, "ctr");
> >    rs6000_debug_reg_print (CR0_REGNO, CR7_REGNO, "cr");
> > @@ -2332,6 +2370,7 @@ rs6000_debug_reg_global (void)
> >  	   "wr reg_class = %s\n"
> >  	   "wx reg_class = %s\n"
> >  	   "wA reg_class = %s\n"
> > +	   "wD reg_class = %s\n"
> >  	   "\n",
> >  	   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_d]],
> >  	   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_v]],
> > @@ -2339,7 +2378,8 @@ rs6000_debug_reg_global (void)
> >  	   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_we]],
> >  	   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wr]],
> >  	   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wx]],
> > -	   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wA]]);
> > +	   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wA]],
> > +	   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wD]]);
> > 
> 
> snip ...
> 
> > +/* Subroutine to determine the move cost of dense math registers.  If we are
> > +   moving to/from VSX_REGISTER registers, the cost is either 1 move (for
> > +   512-bit accumulators) or 2 moves (for 1,024 dmr registers).  If we are
> > +   moving to anything else like GPR registers, make the cost very high.  */
> > +
> > +static int
> > +rs6000_dmr_register_move_cost (machine_mode mode, reg_class_t rclass)
> > +{
> > +  const int reg_move_base = 2;
> > +  HARD_REG_SET vsx_set = (reg_class_contents[rclass]
> > +			  & reg_class_contents[VSX_REGS]);
> > +
> > +  if (TARGET_DENSE_MATH && !hard_reg_set_empty_p (vsx_set))
> 
> Can we just use reg_classes_intersect_p (rclass, VSX_REGS)?
> 
> > +    {
> > +      /* __vector_quad (i.e. XOmode) is tranfered in 1 instruction.  */
> > +      if (mode == XOmode)
> > +	return reg_move_base;
> > +
> > +      else
> > +	return reg_move_base * 2 * hard_regno_nregs (FIRST_DMR_REGNO, mode);
> 
> I guess this "else" arm is for TDOmode, which belongs to that patch.
> 
> > +    }
> > +
> > +  return 1000 * 2 * hard_regno_nregs (FIRST_DMR_REGNO, mode);
> > +}
> > +
> >  /* A C expression returning the cost of moving data from a register of class
> >     CLASS1 to one of CLASS2.  */
> >  
> > @@ -22843,17 +22969,28 @@ rs6000_register_move_cost (machine_mode mode,
> >    if (TARGET_DEBUG_COST)
> >      dbg_cost_ctrl++;
> >  
> 
> snip ...
> 
> >  /* Table of additional register names to use in user input.  */
> > @@ -2132,6 +2158,8 @@ extern char rs6000_reg_names[][8];	/* register names (0 vs. %r0).  */
> >    {"vs52", 84}, {"vs53", 85}, {"vs54", 86}, {"vs55", 87},	\
> >    {"vs56", 88}, {"vs57", 89}, {"vs58", 90}, {"vs59", 91},	\
> >    {"vs60", 92}, {"vs61", 93}, {"vs62", 94}, {"vs63", 95},	\
> > +  {"dmr0", 111}, {"dmr1", 112}, {"dmr2", 113}, {"dmr3", 114},	\
> > +  {"dmr4", 115}, {"dmr5", 116}, {"dmr6", 117}, {"dmr7", 118},	\
> 
> Nit: maybe s/dmr/dm/ to align the previous regnames.
> 
> >  }
> >  
> >  /* This is how to output an element of a case-vector that is relative.  */
> > diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> > index a125fd8fc99..72af3e6ef70 100644
> > --- a/gcc/config/rs6000/rs6000.md
> > +++ b/gcc/config/rs6000/rs6000.md
> > @@ -51,6 +51,8 @@ (define_constants
> >     (VRSAVE_REGNO		108)
> >     (VSCR_REGNO			109)
> >     (FRAME_POINTER_REGNUM	110)
> > +   (FIRST_DMR_REGNO		111)
> > +   (LAST_DMR_REGNO		118)
> >    ])
> >  
> >  ;;
> > @@ -355,7 +357,7 @@ (define_attr "cpu"
> >    (const (symbol_ref "(enum attr_cpu) rs6000_tune")))
> >  
> >  ;; The ISA we implement.
> > -(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p9,p9v,p9kf,p9tf,p10,lxvp,stxvp"
> > +(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p9,p9v,p9kf,p9tf,p10,lxvp,stxvp,dm,not_dm"
> 
> Nit: s/not_dm/nodm/ to align with some previous wording.
> 
> BR,
> Kewen
> 

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

  reply	other threads:[~2024-02-07  0:06 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-05 23:27 Repost [PATCH 0/6] PowerPC Future patches Michael Meissner
2024-01-05 23:35 ` Repost [PATCH 1/6] Add -mcpu=future Michael Meissner
2024-01-19 18:43   ` Ping " Michael Meissner
2024-01-23  8:44   ` Repost " Kewen.Lin
2024-02-06  6:01     ` Michael Meissner
2024-02-07  9:21       ` Kewen.Lin
2024-02-07 19:58         ` Michael Meissner
2024-02-20 10:35           ` Kewen.Lin
2024-02-21  7:19             ` Michael Meissner
2024-02-26 10:46               ` Kewen.Lin
2024-02-23 17:57             ` Segher Boessenkool
2024-02-08 18:42         ` Segher Boessenkool
2024-02-08 18:35       ` Segher Boessenkool
2024-02-08 20:10   ` Segher Boessenkool
2024-01-05 23:37 ` Repost [PATCH 2/6] PowerPC: Make -mcpu=future enable -mblock-ops-vector-pair Michael Meissner
2024-01-19 18:44   ` Ping " Michael Meissner
2024-01-23  8:54   ` Repost " Kewen.Lin
2024-01-05 23:38 ` Repost [PATCH 3/6] PowerPC: Add support for accumulators in DMR registers Michael Meissner
2024-01-19 18:46   ` Ping " Michael Meissner
2024-01-25  9:28   ` Repost " Kewen.Lin
2024-02-07  0:06     ` Michael Meissner [this message]
2024-02-07  9:38       ` Kewen.Lin
2024-02-08  0:26         ` Michael Meissner
2024-01-05 23:39 ` Repost [PATCH 4/6] PowerPC: Make MMA insns support " Michael Meissner
2024-01-19 18:47   ` Ping " Michael Meissner
2024-02-04  3:21   ` Repost " Kewen.Lin
2024-02-07  3:31     ` Michael Meissner
2024-01-05 23:40 ` Repost [PATCH 5/6] PowerPC: Switch to dense math names for all MMA operations Michael Meissner
2024-01-19 18:48   ` Ping " Michael Meissner
2024-02-04  5:47   ` Repost " Kewen.Lin
2024-02-07 20:01     ` Michael Meissner
2024-01-05 23:42 ` Repost [PATCH 6/6] PowerPC: Add support for 1,024 bit DMR registers Michael Meissner
2024-01-19 18:49   ` Ping " Michael Meissner
2024-02-05  3:58   ` Repost " Kewen.Lin
2024-02-08  0:35     ` Michael Meissner
2024-02-08 18:22 ` Repost [PATCH 0/6] PowerPC Future patches 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=ZcLJiTZW0d2Ys3V7@cowardly-lion.the-meissners.org \
    --to=meissner@linux.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@linux.ibm.com \
    --cc=segher@kernel.crashing.org \
    /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).