public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Kewen.Lin" <linkw@linux.ibm.com>
To: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	jeffreyalaw <jeffreyalaw@gmail.com>, rdapp <rdapp@linux.ibm.com>,
	"richard.sandiford" <richard.sandiford@arm.com>,
	rguenther <rguenther@suse.de>
Subject: Re: [PATCH] VECT: Add WHILE_LEN pattern for decrement IV support for auto-vectorization
Date: Fri, 14 Apr 2023 13:40:15 +0800	[thread overview]
Message-ID: <4894ac03-b31e-c3c7-9030-6052ac312df7@linux.ibm.com> (raw)
In-Reply-To: <0B74E8705E17A2A0+2023041411091537265710@rivai.ai>

Hi Juzhe,

>>> Yes, we just wants to add the whole vector register length in bytes.
> OK, I learn it and appreciate you give me the information.
> 
>>> I wonder if you also want WHILE_LEN to have the implicit effect
>>>to update vector length register?
>>>From this perspective, Richi's
>>>suggestion on "tieing the scalar result with the uses" looks better IMHO.
> No, I don't want to make WHILE_LEN have implict side-effect.
> Just tieing the scalar result with the uses.
> Updating vector length register, I let RISC-V backend port to do that.
> I don't want to involve any RISC-V specific feature into GCC middle-end.
> 

Good, thanks for clarifying, that makes more sense.

>>>No, for both cases, IV is variable, the dumping at loop2_doloop for the proposed sequence says
>>>"Doloop: Possible infinite iteration case.", it seems to show that for the proposed sequence compiler
>>>isn't able to figure out the loop is finite, it may miss the range information on n, or it isn't
>>>able to analyze how the invariant involves, but I didn't look into it, all my guesses.
> Ok, I think it may be fixed in the future.

Yeah, it can be.  It only matters for us when adopting --param vect-partial-vector-usage=2 but it's not
default.

> 
> So, I wonder whether you are basically agree with the concept of this patch?
> Would you mind giving more suggestions  that I can fix this patch to make more benefits for IBM (s390 or rs6000)?
> For example, will you try this patch to see whether it can work for IBM in case of multiple rgroup of SLP?

The concept looks good to me, for IBM ports, it can benefit the length preparation for the case of --param
vect-partial-vector-usage=2 (excepting for possible missing doloop chance), it's neutral for the case of
--param vect-partial-vector-usage=1.  IMHO, if possible you can extend the current function vect_set_loop_controls_directly
rather than adding a new function vect_set_loop_controls_by_while_len, since that function does handle both
masks and lengths (controls).  And as vect_gen_len's comments shows, once you change the length preparation,
you have to adjust the corresponding costs as well.  And sure, once this becomes stable (all decisions from
the discussions settled down, gets fully reviewed in stage 1), I'll test it on Power10 and get back to you.

BR,
Kewen

  reply	other threads:[~2023-04-14  5:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-07  1:47 juzhe.zhong
2023-04-07  3:23 ` Li, Pan2
2023-04-11 12:12 ` juzhe.zhong
2023-04-11 12:44   ` Richard Sandiford
2023-04-12  7:00     ` Richard Biener
2023-04-12  8:00       ` juzhe.zhong
2023-04-12  8:42         ` Richard Biener
2023-04-12  9:15           ` juzhe.zhong
2023-04-12  9:29             ` Richard Biener
2023-04-12  9:42               ` Robin Dapp
2023-04-12 11:17               ` Richard Sandiford
2023-04-12 11:37                 ` juzhe.zhong
2023-04-12 12:24                   ` Richard Sandiford
2023-04-12 14:18                     ` 钟居哲
2023-04-13  6:47                       ` Richard Biener
2023-04-13  9:54                         ` juzhe.zhong
2023-04-18  9:32                           ` Richard Sandiford
2023-04-12 12:56                   ` Kewen.Lin
2023-04-12 13:22                     ` 钟居哲
2023-04-13  7:29                       ` Kewen.Lin
2023-04-13 13:44                         ` 钟居哲
2023-04-14  2:54                           ` Kewen.Lin
2023-04-14  3:09                             ` juzhe.zhong
2023-04-14  5:40                               ` Kewen.Lin [this message]
2023-04-14  3:39                             ` juzhe.zhong
2023-04-14  6:31                               ` Kewen.Lin
2023-04-14  6:39                                 ` juzhe.zhong
2023-04-14  7:41                                   ` Kewen.Lin
2023-04-14  6:52                               ` Richard Biener
2023-04-12 11:42                 ` Richard Biener
     [not found]           ` <2023041217154958074655@rivai.ai>
2023-04-12  9:20             ` juzhe.zhong
2023-04-19 21:53 ` 钟居哲
2023-04-20  8:52   ` Richard Sandiford
2023-04-20  8:57     ` juzhe.zhong
2023-04-20  9:11       ` Richard Sandiford
2023-04-20  9:19         ` juzhe.zhong
2023-04-20  9:22           ` Richard Sandiford
2023-04-20  9:50             ` Richard Biener
2023-04-20  9:54               ` Richard Sandiford
2023-04-20 10:38                 ` juzhe.zhong
2023-04-20 12:05                   ` 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=4894ac03-b31e-c3c7-9030-6052ac312df7@linux.ibm.com \
    --to=linkw@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=rdapp@linux.ibm.com \
    --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).