public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "kito at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions
Date: Wed, 08 Nov 2023 01:56:19 +0000	[thread overview]
Message-ID: <bug-112431-4-oR7aLH4Jm7@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-112431-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431

--- Comment #3 from Kito Cheng <kito at gcc dot gnu.org> ---
Share some thought from my end: we've tried at least 3 different approach on
LLVM side before, and now we model that as "partial early clobber", we plan to
upstream  this on LLVM side but just didn't get high enough priority yet :(

What means? Give some practical example to demo the idea:

1. It's normal live range without early clobber

vadd x, y z # y and z is dead after this use.

|---------------------|
| read  |     y    z  |
| write | x           |
|---------------------|


2. It's live range with early clobber.

vadd x, y z # y and z is dead after this use, and assume x is early clobber.

|---------------------|
| read  | x   y    z  |
| write | x           |
|---------------------|


3. It's live range with partial early clobber.

vwadd.vv x, y, z # x is two time larger than y and z

So we split x into xh and xl to represent the high part and low part, and
assume  high part can be overlap with others.

|------------------------|
| read  |    xl  y    z  |
| write | xh xl          |
|------------------------|

And following case is assume high part can overlap with others:

|------------------------|
| read  | xh     y    z  |
| write | xh xl          |
|------------------------|

Then the register allocator should able to did the overlapping allocation
naturally IF we build live range.

  parent reply	other threads:[~2023-11-08  1:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-08  0:15 [Bug c/112431] New: " juzhe.zhong at rivai dot ai
2023-11-08  0:16 ` [Bug c/112431] " juzhe.zhong at rivai dot ai
2023-11-08  0:16 ` juzhe.zhong at rivai dot ai
2023-11-08  1:56 ` kito at gcc dot gnu.org [this message]
2023-11-12 21:18 ` pinskia at gcc dot gnu.org
2023-11-29  9:37 ` [Bug target/112431] " cvs-commit at gcc dot gnu.org
2023-11-30  1:16 ` cvs-commit at gcc dot gnu.org
2023-11-30  2:40 ` cvs-commit at gcc dot gnu.org
2023-11-30 10:50 ` cvs-commit at gcc dot gnu.org
2023-11-30 12:11 ` cvs-commit at gcc dot gnu.org
2023-12-01 12:09 ` cvs-commit at gcc dot gnu.org
2023-12-01 12:09 ` cvs-commit at gcc dot gnu.org
2023-12-04 10:45 ` cvs-commit at gcc dot gnu.org
2023-12-04 11:21 ` juzhe.zhong at rivai dot ai
2023-12-04 13:36 ` cvs-commit at gcc dot gnu.org
2023-12-04 13:48 ` cvs-commit at gcc dot gnu.org
2023-12-11  7:56 ` cvs-commit at gcc dot gnu.org

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=bug-112431-4-oR7aLH4Jm7@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).