From: "juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>
To: palmer <palmer@rivosinc.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
vineetg <vineetg@rivosinc.com>
Cc: kito.cheng <kito.cheng@gmail.com>,
collison <collison@rivosinc.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
Kito.cheng <kito.cheng@sifive.com>,
richard.sandiford <richard.sandiford@arm.com>,
"Richard Biener" <richard.guenther@gmail.com>
Subject: Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant
Date: Tue, 21 Mar 2023 10:02:57 +0800 [thread overview]
Message-ID: <D04AB09795C13180+2023032110025656239826@rivai.ai> (raw)
In-Reply-To: <mhng-b148792d-8af7-486b-9c52-78348740a3c2@palmer-ri-x1c9>
[-- Attachment #1: Type: text/plain, Size: 5304 bytes --]
I would prefer this is the branch based on gcc-13 where we backport
autovec-related patches once they've landed on trunk.
I won't do any development on this branch, instead, I would just use it for releasing my downstream GCC.
I will directly support auto-vectorization on the trunk since the most important thing for our RVV auto-vectorization landing
in GCC is reviewing from Richard Biener && Richard sandiford.
Besides, from my experience of development RVV GCC (rvv-next) and optimization of RVV LLVM (Rivai downstream LLVM). Now, I have a bunch of new ideas
of supporting RVV auto-vectorization. I think we can have a sync up meeting (share my current new ideas) before I start to support RVV auto-vectorization before GCC 14.
juzhe.zhong@rivai.ai
From: Palmer Dabbelt
Date: 2023-03-18 00:57
To: gcc-patches; Vineet Gupta
CC: Kito Cheng; collison; juzhe.zhong; gcc-patches; kito.cheng; richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
On Tue, 14 Mar 2023 10:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
>
>
> On 2/23/23 21:04, Kito Cheng wrote:
>> Hi Jeff:
>>
>>> What I'd been planning to do internally at Ventana was to update our
>>> codebase to gcc-13 once it's released. Then I'd backport RVV autovec
>>> work from the gcc-14 dev tree into that Ventana branch.
>>>
>>> Instead, but along the same lines, we could have a public gcc-13 based
>>> branch which follows that same process and where Rivos, SiFive, Rivai,
>>> Ventana (and potentially others with an interest in this space) could
>>> collaborate. Essentially it'd be gcc-13 + RVV autovec support. We'd
>>> probably have to hash out a bit of policy with the shared branch, but
>>> I'd like to think we could make it work.
>>
>> +1, I like the idea, I could imagine we definitely will do the same
>> work more than four times by different companies if we don't have a
>> collaboration branch...
> So it looks like there's a general sense that a coordination branch off
> gcc-13 is reasonable. So I'd like to hammer out a few details.
>
>
> First, I recommend we cut a branch from gcc-13 soon after gcc-13
> branches. That way we've got a place to land the vector work.
>
> Second, I recommend we rebase that branch periodically so that it
> follows gcc-13. That means downstream consumers may have non-ff pulls,
> but I think we want to follow gcc-13 fairly closely. I'm open to other
> approaches here.
>
> Third, I was thinking that once a patch related to risc-v vectorization
> goes to the trunk, any one of the principals should be able to
> cherry-pick that patch onto our branch.
I'm a little bit confused about what the proposal is here: is the idea
to have a branch based on gcc-13 where we coordinate work before it
lands on trunk, or a branch based on gcc-13 where we backport
autovec-related patches once they've landed on trunk? In my mind those
are actually two different things and I think they're both useful, maybe
we should just do both?
Having a shared work-in-progress branch for the autovec stuff makes
sense to me: it's a big patch set with engineers at multiple companies
working on it, so having a shared patch stack should help with the
coordination. That branch will need to get re-written as patches get
reviewed/merged, so having it rebase seems reasonable. I'd have the
branch based on trunk, as that's the eventual target for the patches,
but trunk can be unstable so maybe that'll be too much of a headache.
For pretty much every other GCC release we've ended up with a "extra
RISC-V backports" branch, where we end up with some patches that aren't
suitable for proper upstream backports (usually because they're a
performance improvement). We've always talked about doing that as a FSF
vendor branch, but I don't think we really ever got organized enough to
do it. We're doing that internally anyway at Rivos and I'd bet everyone
else is too, it'd be great to find some way to share as much of that
work as we can.
It's sort of a headache to just propose doing everything, but in this
case I think we're going to end up with various flavors of both of these
branches internally at the various companies so we might as well just
try and do that in public where we can.
> That implies we need to identify the principals. I'll suggest Kito,
> Juzhe, Michael and myself as the initial list. I'm certainly open to
> others joining.
+Vineet, who's been handling our internal GCC branches.
We'll still have internal branches for 13 regardless of how the autovec
stuff proceeds, but having any sort of upstream backport branch will
make life easier as we'll be able to share some of that work.
> Other thoughts or suggestions?
Sorry if that throws a bit of a wrench in the works.
Just for context: in Rivos land we don't have any specific timelines
around 13, so the goal on our end is just to keep the vectorization
stuff progressing smoothly as we spin up more engineering resources on
it. Our aim is just to get everything on trunk eventually, anything
else is just a stop-gap and we can work around it (though sharing that
work is always a win).
>
> Jeff
next prev parent reply other threads:[~2023-03-21 2:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 15:27 juzhe.zhong
2023-02-22 17:54 ` Michael Collison
2023-02-22 23:43 ` juzhe.zhong
2023-02-22 23:47 ` juzhe.zhong
2023-02-23 4:01 ` Jeff Law
2023-02-23 4:25 ` juzhe.zhong
2023-02-23 4:50 ` Michael Collison
2023-02-24 3:34 ` Jeff Law
2023-02-24 4:04 ` Kito Cheng
2023-03-14 17:48 ` Jeff Law
2023-03-17 16:57 ` Palmer Dabbelt
2023-03-17 16:57 ` Palmer Dabbelt
2023-03-21 2:02 ` juzhe.zhong [this message]
2023-03-23 23:18 ` Jeff Law
2023-03-24 2:28 ` Palmer Dabbelt
2023-03-25 22:45 ` Jeff Law
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=D04AB09795C13180+2023032110025656239826@rivai.ai \
--to=juzhe.zhong@rivai.ai \
--cc=collison@rivosinc.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kito.cheng@gmail.com \
--cc=kito.cheng@sifive.com \
--cc=palmer@rivosinc.com \
--cc=richard.guenther@gmail.com \
--cc=richard.sandiford@arm.com \
--cc=vineetg@rivosinc.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).