public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Richard Sandiford <richard.sandiford@arm.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 5/6] Allow poly_uint64 for group_size args to vector type query routines
Date: Fri, 15 Dec 2023 08:38:39 +0100 (CET)	[thread overview]
Message-ID: <9366n2os-600q-rs42-o027-9s38668363q9@fhfr.qr> (raw)
In-Reply-To: <mptfs04pl2r.fsf@arm.com>

On Thu, 14 Dec 2023, Richard Sandiford wrote:

> Richard Biener <rguenther@suse.de> writes:
> > The following changes the unsigned group_size argument to a poly_uint64
> > one to avoid too much special-casing in callers for VLA vectors when
> > passing down the effective maximum desirable vector size to vector
> > type query routines.  The intent is to be able to pass down
> > the vectorization factor (times the SLP group size) eventually.
> >
> > 	* tree-vectorizer.h (get_vectype_for_scalar_type,
> > 	get_mask_type_for_scalar_type, vect_get_vector_types_for_stmt):
> > 	Change group_size argument to poly_uint64 type.
> > 	(vect_get_mask_type_for_stmt): Remove prototype for no longer
> > 	existing function.
> > 	* tree-vect-stmts.cc (get_vectype_for_scalar_type): Change
> > 	group_size argument to poly_uint64.
> > 	(get_mask_type_for_scalar_type): Likewise.
> > 	(vect_get_vector_types_for_stmt): Likewise.
> 
> LGTM FWIW, although...
> 
> > ---
> >  gcc/tree-vect-stmts.cc | 25 ++++++++++++++-----------
> >  gcc/tree-vectorizer.h  |  7 +++----
> >  2 files changed, 17 insertions(+), 15 deletions(-)
> >
> > diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> > index 88401a2a00b..a5e26b746fb 100644
> > --- a/gcc/tree-vect-stmts.cc
> > +++ b/gcc/tree-vect-stmts.cc
> > @@ -13297,14 +13297,14 @@ get_related_vectype_for_scalar_type (machine_mode prevailing_mode,
> >  
> >  tree
> >  get_vectype_for_scalar_type (vec_info *vinfo, tree scalar_type,
> > -			     unsigned int group_size)
> > +			     poly_uint64 group_size)
> >  {
> >    /* For BB vectorization, we should always have a group size once we've
> >       constructed the SLP tree; the only valid uses of zero GROUP_SIZEs
> >       are tentative requests during things like early data reference
> >       analysis and pattern recognition.  */
> >    if (is_a <bb_vec_info> (vinfo))
> > -    gcc_assert (vinfo->slp_instances.is_empty () || group_size != 0);
> > +    gcc_assert (vinfo->slp_instances.is_empty () || known_ne (group_size, 0));
> >    else
> >      group_size = 0;
> >  
> > @@ -13320,9 +13320,11 @@ get_vectype_for_scalar_type (vec_info *vinfo, tree scalar_type,
> >  
> >    /* If the natural choice of vector type doesn't satisfy GROUP_SIZE,
> >       try again with an explicit number of elements.  */
> > +  uint64_t cst_group_size;
> >    if (vectype
> > -      && group_size
> > -      && maybe_ge (TYPE_VECTOR_SUBPARTS (vectype), group_size))
> > +      && group_size.is_constant (&cst_group_size)
> > +      && cst_group_size != 0
> > +      && maybe_ge (TYPE_VECTOR_SUBPARTS (vectype), cst_group_size))
> >      {
> >        /* Start with the biggest number of units that fits within
> >  	 GROUP_SIZE and halve it until we find a valid vector type.
> 
> ...it feels like this makes sense for VLA too in some form, if we
> plan to keep it longer-term.  It's not a trivial adaption though,
> so would definitely be a separate patch.

I did wonder if it's even possible to have multiple VLA vector sizes
but then you do have these x2 and x4 modes which are exactly that,
VLA vectors with a multiple number of elements?

So practically the goal is to find a vector mode suitable for a given
vectorization factor rather than a "size".

Richard.


> Thanks,
> Richard
> 
> > @@ -13336,7 +13338,7 @@ get_vectype_for_scalar_type (vec_info *vinfo, tree scalar_type,
> >  	 even though the group is not a multiple of that vector size.
> >  	 The BB vectorizer will then try to carve up the group into
> >  	 smaller pieces.  */
> > -      unsigned int nunits = 1 << floor_log2 (group_size);
> > +      unsigned int nunits = 1 << floor_log2 (cst_group_size);
> >        do
> >  	{
> >  	  vectype = get_related_vectype_for_scalar_type (vinfo->vector_mode,
> > @@ -13372,7 +13374,7 @@ get_vectype_for_scalar_type (vec_info *vinfo, tree scalar_type, slp_tree node)
> >  
> >  tree
> >  get_mask_type_for_scalar_type (vec_info *vinfo, tree scalar_type,
> > -			       unsigned int group_size)
> > +			       poly_uint64 group_size)
> >  {
> >    tree vectype = get_vectype_for_scalar_type (vinfo, scalar_type, group_size);
> >  
> > @@ -14243,7 +14245,7 @@ opt_result
> >  vect_get_vector_types_for_stmt (vec_info *vinfo, stmt_vec_info stmt_info,
> >  				tree *stmt_vectype_out,
> >  				tree *nunits_vectype_out,
> > -				unsigned int group_size)
> > +				poly_uint64 group_size)
> >  {
> >    gimple *stmt = stmt_info->stmt;
> >  
> > @@ -14252,7 +14254,7 @@ vect_get_vector_types_for_stmt (vec_info *vinfo, stmt_vec_info stmt_info,
> >       are tentative requests during things like early data reference
> >       analysis and pattern recognition.  */
> >    if (is_a <bb_vec_info> (vinfo))
> > -    gcc_assert (vinfo->slp_instances.is_empty () || group_size != 0);
> > +    gcc_assert (vinfo->slp_instances.is_empty () || known_ne (group_size, 0));
> >    else
> >      group_size = 0;
> >  
> > @@ -14281,7 +14283,7 @@ vect_get_vector_types_for_stmt (vec_info *vinfo, stmt_vec_info stmt_info,
> >  
> >    tree vectype;
> >    tree scalar_type = NULL_TREE;
> > -  if (group_size == 0 && STMT_VINFO_VECTYPE (stmt_info))
> > +  if (known_eq (group_size, 0U) && STMT_VINFO_VECTYPE (stmt_info))
> >      {
> >        vectype = STMT_VINFO_VECTYPE (stmt_info);
> >        if (dump_enabled_p ())
> > @@ -14310,10 +14312,11 @@ vect_get_vector_types_for_stmt (vec_info *vinfo, stmt_vec_info stmt_info,
> >  
> >        if (dump_enabled_p ())
> >  	{
> > -	  if (group_size)
> > +	  if (known_ne (group_size, 0U))
> >  	    dump_printf_loc (MSG_NOTE, vect_location,
> >  			     "get vectype for scalar type (group size %d):"
> > -			     " %T\n", group_size, scalar_type);
> > +			     " %T\n", (int)constant_lower_bound (group_size),
> > +			     scalar_type);
> >  	  else
> >  	    dump_printf_loc (MSG_NOTE, vect_location,
> >  			     "get vectype for scalar type: %T\n", scalar_type);
> > diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
> > index a2bab8676af..95240504d18 100644
> > --- a/gcc/tree-vectorizer.h
> > +++ b/gcc/tree-vectorizer.h
> > @@ -2204,9 +2204,9 @@ extern edge vec_init_loop_exit_info (class loop *);
> >  /* In tree-vect-stmts.cc.  */
> >  extern tree get_related_vectype_for_scalar_type (machine_mode, tree,
> >  						 poly_uint64 = 0);
> > -extern tree get_vectype_for_scalar_type (vec_info *, tree, unsigned int = 0);
> > +extern tree get_vectype_for_scalar_type (vec_info *, tree, poly_uint64 = 0);
> >  extern tree get_vectype_for_scalar_type (vec_info *, tree, slp_tree);
> > -extern tree get_mask_type_for_scalar_type (vec_info *, tree, unsigned int = 0);
> > +extern tree get_mask_type_for_scalar_type (vec_info *, tree, poly_uint64 = 0);
> >  extern tree get_mask_type_for_scalar_type (vec_info *, tree, slp_tree);
> >  extern tree get_same_sized_vectype (tree, tree);
> >  extern bool vect_chooses_same_modes_p (vec_info *, machine_mode);
> > @@ -2295,8 +2295,7 @@ extern tree vect_gen_while (gimple_seq *, tree, tree, tree,
> >  extern tree vect_gen_while_not (gimple_seq *, tree, tree, tree);
> >  extern opt_result vect_get_vector_types_for_stmt (vec_info *,
> >  						  stmt_vec_info, tree *,
> > -						  tree *, unsigned int = 0);
> > -extern opt_tree vect_get_mask_type_for_stmt (stmt_vec_info, unsigned int = 0);
> > +						  tree *, poly_uint64 = 0);
> >  
> >  /* In tree-vect-data-refs.cc.  */
> >  extern bool vect_can_force_dr_alignment_p (const_tree, poly_uint64);
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

  reply	other threads:[~2023-12-15  7:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20231213123247.47A3838708F9@sourceware.org>
2023-12-14 20:48 ` Richard Sandiford
2023-12-15  7:38   ` Richard Biener [this message]
2023-12-13 12:31 Richard Biener

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=9366n2os-600q-rs42-o027-9s38668363q9@fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.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).