public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Hongtao Liu <crazylht@gmail.com>
Cc: Hongtao Liu via Gcc-patches <gcc-patches@gcc.gnu.org>,
	Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH] [PR rtl-optimization/97249]Simplify vec_select of paradoxical subreg.
Date: Tue, 20 Oct 2020 17:42:25 +0100	[thread overview]
Message-ID: <mptmu0g6e8e.fsf@arm.com> (raw)
In-Reply-To: <CAMZc-bwKQOD9s3xPpkemE2yFUrrgrJ_NGMbYc-dZKA3-V2YqEg@mail.gmail.com> (Hongtao Liu's message of "Tue, 20 Oct 2020 11:20:48 +0800")

Hongtao Liu <crazylht@gmail.com> writes:
>> > +           && (GET_MODE_NUNITS (mode)).is_constant (&l1)
>> > +           && (GET_MODE_NUNITS (GET_MODE (SUBREG_REG (trueop0))))
>> > +               .is_constant (&l2)
>> > +           && known_le (l1, l2)
>>
>> I'm not sure the last two &&s are really the important condition.
>> I think we should drop them for the suggestion below.
>>
>
> Changed, assume gcc also support something like (vec_select:v4di
> (reg:v2di) (parallel [ (const_int 0) (const_int 1) (const_int 1)
> (const_int 0)]))
> as long as the range of selection guaranteed by
>   || maybe_ge (UINTVAL (idx) + subreg_offset, nunits))

Yeah, that vec_select looks OK.

>>
>> > +               if (!CONST_INT_P (idx))
>>
>> Here I think we should check:
>>
>>                       || maybe_ge (UINTVAL (idx) + subreg_offset, nunits))
>>
>> where:
>>
>>        poly_uint64 nunits
>>          = GET_MODE_NUNITS (GET_MODE (SUBREG_REG (trueop0)))).
>>
>
> Changed.
>
>> This makes sure that all indices are in range.  In particular, it's
>> valid for the SUBREG_REG to be narrower than mode, for appropriate
>> vec_select indices
>>
>
> Yes, that's what paradoxical subreg means.

But I was comparing the mode of the vec_select with the mode of the
SUBREG_REG (rather than the mode of trueop0 with the mode of the
SUBREG_REG, which is what matters for paradoxical subregs).

> +	  /* Simplify vec_select of a subreg of X to just a vec_select of X
> +	     when X has same component mode as vec_select.  */
> +	  unsigned HOST_WIDE_INT subreg_offset = 0;
> +	  if (GET_CODE (trueop0) == SUBREG
> +	      && GET_MODE_INNER (mode)
> +		 == GET_MODE_INNER (GET_MODE (SUBREG_REG (trueop0)))
> +	      && (GET_MODE_NUNITS (mode)).is_constant (&l1)

Unnecessary brackets around “GET_MODE_NUNITS (mode)”.

> +	      && constant_multiple_p (SUBREG_BYTE (trueop0),
> +				      GET_MODE_UNIT_BITSIZE (mode),
> +				      &subreg_offset))

Sorry, my bad, this should be:

	      && constant_multiple_p (subreg_memory_offset (trueop0),
				      GET_MODE_UNIT_BITSIZE (mode),
				      &subreg_offset))

> +	    {
> +	      gcc_assert (XVECLEN (trueop1, 0) == l1);
> +	      bool success = true;
> +	      poly_uint64 nunits
> +		= GET_MODE_NUNITS (GET_MODE (SUBREG_REG (trueop0)));
> +	      for (int i = 0; i != l1; i++)
> +		{
> +		  rtx idx = XVECEXP (trueop1, 0, i);
> +		  if (!CONST_INT_P (idx)
> +		      || maybe_ge (UINTVAL (idx) + subreg_offset, nunits))
> +		    {
> +		      success = false;
> +		      break;
> +		    }
> +		}
> +	      if (success)
> +		{
> +		  rtx par = trueop1;
> +		  if (subreg_offset)
> +		    {
> +		      rtvec vec = rtvec_alloc (l1);
> +		      for (int i = 0; i < l1; i++)
> +			RTVEC_ELT (vec, i)
> +			  = GEN_INT (INTVAL (XVECEXP (trueop1, 0, i)
> +					     + subreg_offset));

This is applying subreg_offset to the pointer rather than the INTVAL.
It should be:

			  = GEN_INT (UINTVAL (XVECEXP (trueop1, 0, i))
				     + subreg_offset);

OK with those changes, thanks.

Richard

  reply	other threads:[~2020-10-20 16:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13  8:40 Hongtao Liu
2020-10-13 19:59 ` Segher Boessenkool
2020-10-14  5:43   ` Hongtao Liu
2020-10-14 17:35     ` Segher Boessenkool
2020-10-14 17:55       ` Richard Biener
2020-10-14 19:23         ` Segher Boessenkool
2020-10-15  8:14       ` Hongtao Liu
2020-10-15  9:58         ` Hongtao Liu
2020-10-15 12:38           ` Richard Sandiford
2020-10-19  5:18             ` Hongtao Liu
2020-10-19 15:31               ` Richard Sandiford
2020-10-20  3:20                 ` Hongtao Liu
2020-10-20 16:42                   ` Richard Sandiford [this message]
2020-10-21  2:43                     ` Hongtao Liu
2020-10-20 21:05                   ` Segher Boessenkool
2020-10-21  3:17                     ` Hongtao Liu
2020-10-21 15:43                       ` Richard Sandiford
2020-10-21 16:34                         ` Segher Boessenkool
2020-10-22  3:33                           ` Hongtao Liu
2020-10-20 20:43         ` 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=mptmu0g6e8e.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=crazylht@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).