public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>
To: Richard Biener <rguenther@suse.de>,
	Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>,
	 gcc Patches <gcc-patches@gcc.gnu.org>,
	richard.sandiford@arm.com
Subject: Re: [2/2] PR96463 -- changes to type checking vec_perm_expr in middle end
Date: Tue, 3 May 2022 16:11:27 +0530	[thread overview]
Message-ID: <CAAgBjM=-tgaRsXJPRSG47r_JyLJSBsQnfD5YHUE5M9efUybiyA@mail.gmail.com> (raw)
In-Reply-To: <mptzgob1utb.fsf@arm.com>

[-- Attachment #1: Type: text/plain, Size: 3276 bytes --]

On Tue, 4 Jan 2022 at 19:12, Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Richard Biener <rguenther@suse.de> writes:
> > On Tue, 4 Jan 2022, Richard Sandiford wrote:
> >
> >> Richard Biener <rguenther@suse.de> writes:
> >> > On Fri, 17 Dec 2021, Richard Sandiford wrote:
> >> >
> >> >> Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> writes:
> >> >> > Hi,
> >> >> > The attached patch rearranges order of type-check for vec_perm_expr
> >> >> > and relaxes type checking for
> >> >> > lhs = vec_perm_expr<rhs1, rhs2, mask>
> >> >> >
> >> >> > when:
> >> >> > rhs1 == rhs2,
> >> >> > lhs is variable length vector,
> >> >> > rhs1 is fixed length vector,
> >> >> > TREE_TYPE (lhs) == TREE_TYPE (rhs1)
> >> >> >
> >> >> > I am not sure tho if this check is correct ? My intent was to capture
> >> >> > case when vec_perm_expr is used to "extend" fixed length vector to
> >> >> > it's VLA equivalent.
> >> >>
> >> >> VLAness isn't really the issue.  We want the same thing to work for
> >> >> -msve-vector-bits=256, -msve-vector-bits=512, etc., even though the
> >> >> vectors are fixed-length in that case.
> >> >>
> >> >> The principle is that for:
> >> >>
> >> >>   A = VEC_PERM_EXPR <B, C, D>;
> >> >>
> >> >> the requirements are:
> >> >>
> >> >> - A, B, C and D must be vectors
> >> >> - A, B and C must have the same element type
> >> >> - D must have an integer element type
> >> >> - A and D must have the same number of elements (NA)
> >> >> - B and C must have the same number of elements (NB)
> >> >>
> >> >> The semantics are that we create a joined vector BC (all elements of B
> >> >> followed by all element of C) and that:
> >> >>
> >> >>   A[i] = BC[D[i] % (NB+NB)]
> >> >>
> >> >> for 0 ≤ i < NA.
> >> >>
> >> >> This operation makes sense even if NA != NB.
> >> >
> >> > But note that we don't currently expect NA != NB and the optab just
> >> > has a single mode.
> >>
> >> True, but we only need this for constant permutes.  They are already
> >> special in that they allow the index elements to be wider than the data
> >> elements.
> >
> > OK, then we should reflect this in the stmt verification and only relax
> > the constant permute vector case and also amend the
> > TARGET_VECTORIZE_VEC_PERM_CONST accordingly.
>
> Sounds good.
>
> > For non-constant permutes the docs say the mode of vec_perm is
> > the common mode of operands 1 and 2 whilst the mode of operand 0
> > is unspecified - even unconstrained by the docs.  I'm not sure
> > if vec_perm expansion is expected to eventually FAIL.  Updating the
> > docs of vec_perm would be appreciated as well.
>
> Yeah, I guess de facto operand 0 has to be the same mode as operands
> 1 and 2.  Maybe that was just an oversight, or maybe it seemed obvious
> or self-explanatory at the time. :-)
>
> > As said I prefer to not mangle the existing stmt checking too much
> > at this stage so minimal adjustment is prefered there.
>
> The PR is only an enhancement request rather than a bug, so I think the
> patch would need to wait for GCC 13 whatever happens.
Hi,
In attached patch, the type checking is relaxed only if mask is constant.
Does this look OK ?

Thanks,
Prathamesh
>
> Thanks,
> Richard

[-- Attachment #2: pr96463-5-midend.txt --]
[-- Type: text/plain, Size: 1136 bytes --]

diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index e321d929fd0..02b88f67855 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -4307,6 +4307,24 @@ verify_gimple_assign_ternary (gassign *stmt)
       break;
 
     case VEC_PERM_EXPR:
+      /* If permute is constant, then we allow for lhs and rhs
+	 to have different vector types, provided:
+	 (1) lhs, rhs1, rhs2, and rhs3 have same element type.
+	 (2) rhs3 vector has integer element type.
+	 (3) len(lhs) == len(rhs3) && len(rhs1) == len(rhs2).  */
+
+      if (TREE_CONSTANT (rhs3)
+	  && VECTOR_TYPE_P (lhs_type)
+	  && VECTOR_TYPE_P (rhs1_type)
+	  && VECTOR_TYPE_P (rhs2_type)
+	  && VECTOR_TYPE_P (rhs3_type)
+	  && TREE_TYPE (lhs_type) == TREE_TYPE (rhs1_type)
+	  && TREE_TYPE (lhs_type) == TREE_TYPE (rhs2_type)
+	  && INTEGRAL_TYPE_P (TREE_TYPE (rhs3_type))
+	  && known_eq (TYPE_VECTOR_SUBPARTS (lhs_type), TYPE_VECTOR_SUBPARTS (rhs3_type))
+	  && known_eq (TYPE_VECTOR_SUBPARTS (rhs1_type), TYPE_VECTOR_SUBPARTS (rhs2_type)))
+	return false;
+
       if (!useless_type_conversion_p (lhs_type, rhs1_type)
 	  || !useless_type_conversion_p (lhs_type, rhs2_type))
 	{

  reply	other threads:[~2022-05-03 10:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 10:05 Prathamesh Kulkarni
2021-12-17 11:07 ` Richard Sandiford
2021-12-27 10:25   ` Prathamesh Kulkarni
2022-01-03 10:40   ` Richard Biener
2022-01-04 11:50     ` Richard Sandiford
2022-01-04 12:40       ` Richard Biener
2022-01-04 13:42         ` Richard Sandiford
2022-05-03 10:41           ` Prathamesh Kulkarni [this message]
2022-05-03 12:55             ` Richard Sandiford
2022-05-09 11:21               ` Prathamesh Kulkarni
2022-05-09 13:52                 ` Richard Sandiford
2022-05-09 15:51                   ` Prathamesh Kulkarni
2022-05-23 17:27                     ` Prathamesh Kulkarni
2022-05-31 11:35                       ` Prathamesh Kulkarni
2022-06-01  7:58                         ` 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='CAAgBjM=-tgaRsXJPRSG47r_JyLJSBsQnfD5YHUE5M9efUybiyA@mail.gmail.com' \
    --to=prathamesh.kulkarni@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    --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).