public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: "juzhe.zhong\@rivai.ai" <juzhe.zhong@rivai.ai>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,  rguenther <rguenther@suse.de>
Subject: Re: [PATCH V7] VECT: Add decrement IV support in Loop Vectorizer
Date: Tue, 16 May 2023 09:16:17 +0100	[thread overview]
Message-ID: <mpto7mk3d4e.fsf@arm.com> (raw)
In-Reply-To: <2BEA9A36F71A96BC+2023051615392250169239@rivai.ai> (juzhe's message of "Tue, 16 May 2023 15:39:23 +0800")

"juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai> writes:
> Oh, 
> I am sorry for incorrect typos in the last email, fix typos :
>
> Hi, Richard.
> For case 2, I come up with this idea:
> +	     Case 2 (SLP multiple rgroup):
> +		...
> +		_38 = (unsigned long) n_12(D);
> +		_39 = _38 * 2;
> +		_40 = MAX_EXPR <_39, 16>;   ----------------->remove
> +		_41 = _40 - 16; ----------------->remove
>
> +		...
> +		# ivtmp_42 = PHI <ivtmp_43(4), _41(3)>  ----------------->remove
>
> +		# ivtmp_45 = PHI <ivtmp_46(4), _39(3)>
> +		...
> +		_44 = MIN_EXPR <ivtmp_42, 32>;  ----------------->remove
>
> +		_47 = MIN_EXPR <ivtmp_45, 32>;+               _47_2 = MIN_EXPR <_47, 16>;  -------->add+               _47_3 = _47 - _47_2 ; --------> add
> +		...
> +		.LEN_STORE (_6, 8B, _47_2, ...);
> +		...
> +		.LEN_STORE (_25, 8B, _47_3, ...);
> +		_33 = _47_2 / 2;
> +		...
> +		.LEN_STORE (_8, 16B, _33, ...);
> +		_36 = _47_3 / 2;
> +		...
> +		.LEN_STORE (_15, 16B, _36, ...);
> +		ivtmp_46 = ivtmp_45 - _47;
> +		ivtmp_43 = ivtmp_42 - _44;  ----------------->remove
>
> +		...
> +		if (ivtmp_46 != 0)
> +		  goto <bb 4>; [83.33%]
> +		else
> +		  goto <bb 5>; [16.67%]
> Is it reasonable ? Or you do have better idea for it?

Yeah, this makes sense, and I think it makes case 2 very similar
(equivalent?) to case 3.  If so, it would be nice if they could be
combined.

Of course, this loses the nice property that the original had: that each
IV was independent, and so the dependency chains were shorter.  With the
above approach, the second length parameter instead depends on a
three-instruction chain.  But that might be OK (up to you).

How much of the riscv backend infrastructure is in place now?  The reason
I ask is that it would be good if the patch had some tests.  AIUI, the
patch is an optimisation on top of what the current len_load/store code does,
rather than something that is needed for correctness.  So it seems like
the necessary patterns could be added and tested using the current approach,
then this patch could be applied on top, with its own tests for the new
approach.

Thanks,
Richard

  reply	other threads:[~2023-05-16  8:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15  1:28 juzhe.zhong
2023-05-15 19:44 ` Richard Sandiford
2023-05-15 21:20   ` 钟居哲
2023-05-16  4:32   ` juzhe.zhong
2023-05-16  6:57     ` Richard Sandiford
2023-05-16  7:22       ` juzhe.zhong
2023-05-16  7:35       ` juzhe.zhong
2023-05-16  7:39       ` juzhe.zhong
2023-05-16  8:16         ` Richard Sandiford [this message]
2023-05-16  8:23           ` juzhe.zhong
2023-05-16  8:30             ` Richard Sandiford
2023-05-16  9:25               ` juzhe.zhong
2023-05-16 10:25               ` juzhe.zhong
2023-05-16 11:23               ` juzhe.zhong

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=mpto7mk3d4e.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=juzhe.zhong@rivai.ai \
    --cc=rguenther@suse.de \
    /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).