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.
next prev 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: linkBe 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).