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
