Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Palmer Dabbelt <palmer@rivosinc.com>]

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