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)
next prev parent 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).