GCC-13 Branch with RISC-V Performance-Related Backports

GCC-13 Branch with RISC-V Performance-Related Backports

[Palmer Dabbelt]

Based on some discussions, it looks like a handful of vendors are 
planning on maintaining GCC-13 branches that include various 
performance-related backports (ie, patches not suitable for the standard 
GCC-13 release branch).

I don't think we'd actually agreed to a set of branch rules, but it 
seems like the following were where the discussion ended up:

* Make a "riscv" vendor branch.  I don't think we came up with a name, 
  but "riscv/gcc-13-perf" seems fine to me.
* Regularly rebase the branch on the GCC-13 release branch.
* Only accept backports that have landed on trunk.

There's a few others that I'd like to add, just based on poking around:

* No new regressions for anything that's backported.
* Use "git cherry-pick -x" from the trunk commit.

We're starting to land some gcc-14 patches already, so I'd prefer to 
make the branch sooner rather than later.  Unless there's any 
objections, I'll push what's at 
github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Jeff Law]

On 4/17/23 12:50, Palmer Dabbelt wrote:
> Based on some discussions, it looks like a handful of vendors are 
> planning on maintaining GCC-13 branches that include various 
> performance-related backports (ie, patches not suitable for the standard 
> GCC-13 release branch).
> 
> I don't think we'd actually agreed to a set of branch rules, but it 
> seems like the following were where the discussion ended up:
> 
> * Make a "riscv" vendor branch.  I don't think we came up with a name, 
>   but "riscv/gcc-13-perf" seems fine to me.
> * Regularly rebase the branch on the GCC-13 release branch.
> * Only accept backports that have landed on trunk.
> 
> There's a few others that I'd like to add, just based on poking around:
> 
> * No new regressions for anything that's backported.
> * Use "git cherry-pick -x" from the trunk commit.
Works for me.

> 
> We're starting to land some gcc-14 patches already, so I'd prefer to 
> make the branch sooner rather than later.  Unless there's any 
> objections, I'll push what's at 
> github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.
Sounds good to me.

FWIW, the few bits I've pushed to-date didn't seem important enough to 
me to warrant porting to this branch.  But if someone thinks otherwise, 
I won't object to them being cherry-picked.

jeff

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Kito Cheng]

> > Based on some discussions, it looks like a handful of vendors are
> > planning on maintaining GCC-13 branches that include various
> > performance-related backports (ie, patches not suitable for the standard
> > GCC-13 release branch).

Did you consider also include necessary vectorizeor stuffs? I expect there would
be some patch in middle end for enable auto vec, like this:

https://patchwork.ozlabs.org/project/gcc/patch/20230407014741.139387-1-juzhe.zhong@rivai.ai/

> >
> > I don't think we'd actually agreed to a set of branch rules, but it
> > seems like the following were where the discussion ended up:
> >
> > * Make a "riscv" vendor branch.  I don't think we came up with a name,
> >   but "riscv/gcc-13-perf" seems fine to me.
> > * Regularly rebase the branch on the GCC-13 release branch.

I would prefer merge rather than rebase since let us have a stable
sha1 as some reference point.

> > * Only accept backports that have landed on trunk.
> >
> > There's a few others that I'd like to add, just based on poking around:
> >
> > * No new regressions for anything that's backported.
> > * Use "git cherry-pick -x" from the trunk commit.
> Works for me.
>
> >
> > We're starting to land some gcc-14 patches already, so I'd prefer to
> > make the branch sooner rather than later.  Unless there's any
> > objections, I'll push what's at
> > github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.
> Sounds good to me.
>
> FWIW, the few bits I've pushed to-date didn't seem important enough to
> me to warrant porting to this branch.  But if someone thinks otherwise,
> I won't object to them being cherry-picked.
>
> jeff

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]


Palmer Dabbelt <palmer@dabbelt.com> writes:

> Based on some discussions, it looks like a handful of vendors are
> planning on maintaining GCC-13 branches that include various
> performance-related backports (ie, patches not suitable for the
> standard GCC-13 release branch).
>
> I don't think we'd actually agreed to a set of branch rules, but it
> seems like the following were where the discussion ended up:
>
> * Make a "riscv" vendor branch.  I don't think we came up with a name,
>   but "riscv/gcc-13-perf" seems fine to me.
> * Regularly rebase the branch on the GCC-13 release branch.
> * Only accept backports that have landed on trunk.

I'm a bit concerned about how distributions are supposed to handle this.

I can see riscv enthusiasts asking us to package the vendor branch -
which presumably won't get automatic snapshots created, so that's a bit
more manual work already. But supposing we switched to it entirely for
riscv, that might be ok. But what if there's also users who want the
conservative setup?

This feels (not to be a downer, sorry!) like a mess in the making
from the distribution perspective.

I've got to ask: given riscv isn't yet (as far as I understand), a
"premier platform" in GCC terms, couldn't you just be more liberal
with backports for riscv at least up until 13.2, or similar?

This is also a lot of work for a platform I don't even have access to
(we have Gentoo developers with riscv hardware, but not sure any of
it is powerful enough to be regularly testing this in addition to
the regular branch for riscv). If even a handful of other arches started
doing this, I would be completely overwhelmed with work.

Would this also be a long-term thing or just for 13?

>
> There's a few others that I'd like to add, just based on poking around:
>
> * No new regressions for anything that's backported.
> * Use "git cherry-pick -x" from the trunk commit.
>
> We're starting to land some gcc-14 patches already, so I'd prefer to
> make the branch sooner rather than later.  Unless there's any
> objections, I'll push what's at
> github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.

thanks,
sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Jeff Law]

On 4/18/23 04:34, Kito Cheng wrote:
>>> Based on some discussions, it looks like a handful of vendors are
>>> planning on maintaining GCC-13 branches that include various
>>> performance-related backports (ie, patches not suitable for the standard
>>> GCC-13 release branch).
> 
> Did you consider also include necessary vectorizeor stuffs? I expect there would
> be some patch in middle end for enable auto vec, like this:
> 
> https://patchwork.ozlabs.org/project/gcc/patch/20230407014741.139387-1-juzhe.zhong@rivai.ai/
I think to some degree middle end patches are inevitable.  I think the 
same basic guidelines applies.  If it's on the trunk, then pulling it 
over to our branch is implicitly OK.

> 
>>>
>>> I don't think we'd actually agreed to a set of branch rules, but it
>>> seems like the following were where the discussion ended up:
>>>
>>> * Make a "riscv" vendor branch.  I don't think we came up with a name,
>>>    but "riscv/gcc-13-perf" seems fine to me.
>>> * Regularly rebase the branch on the GCC-13 release branch.
> 
> I would prefer merge rather than rebase since let us have a stable
> sha1 as some reference point.
I slightly prefer the rebase approach.  Its easier to see where we are 
relative to the current gcc-13 bits.  Doing an occasional forced update 
isn't that bad (I've worked with this kind of flow for shared topic 
branches in the past).  But if you feel strongly, I can live with a 
merge flow as well.

Jeff

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Palmer Dabbelt]

On Tue, 18 Apr 2023 06:19:07 PDT (-0700), jeffreyalaw@gmail.com wrote:
>
>
> On 4/18/23 04:34, Kito Cheng wrote:
>>>> Based on some discussions, it looks like a handful of vendors are
>>>> planning on maintaining GCC-13 branches that include various
>>>> performance-related backports (ie, patches not suitable for the standard
>>>> GCC-13 release branch).
>>
>> Did you consider also include necessary vectorizeor stuffs? I expect there would
>> be some patch in middle end for enable auto vec, like this:
>>
>> https://patchwork.ozlabs.org/project/gcc/patch/20230407014741.139387-1-juzhe.zhong@rivai.ai/
> I think to some degree middle end patches are inevitable.  I think the
> same basic guidelines applies.  If it's on the trunk, then pulling it
> over to our branch is implicitly OK.

Yep: I'd actually argue that middle-end patches are the reason we need a 
branch.  We're already somewhat libaral about backporting RISC-V backend 
patches, but there's going to be more substantial middle-end changes.

>>>> I don't think we'd actually agreed to a set of branch rules, but it
>>>> seems like the following were where the discussion ended up:
>>>>
>>>> * Make a "riscv" vendor branch.  I don't think we came up with a name,
>>>>    but "riscv/gcc-13-perf" seems fine to me.
>>>> * Regularly rebase the branch on the GCC-13 release branch.
>>
>> I would prefer merge rather than rebase since let us have a stable
>> sha1 as some reference point.
> I slightly prefer the rebase approach.  Its easier to see where we are
> relative to the current gcc-13 bits.  Doing an occasional forced update
> isn't that bad (I've worked with this kind of flow for shared topic
> branches in the past).  But if you feel strongly, I can live with a
> merge flow as well.

I also think rebasing is slightly better, but not strongly.

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Palmer Dabbelt]

We talked about this a bit on IRC, but just to reflect it to the mailing 
lists:

On Tue, 18 Apr 2023 05:34:11 PDT (-0700), sam@gentoo.org wrote:
>
> Palmer Dabbelt <palmer@dabbelt.com> writes:
>
>> Based on some discussions, it looks like a handful of vendors are
>> planning on maintaining GCC-13 branches that include various
>> performance-related backports (ie, patches not suitable for the
>> standard GCC-13 release branch).
>>
>> I don't think we'd actually agreed to a set of branch rules, but it
>> seems like the following were where the discussion ended up:
>>
>> * Make a "riscv" vendor branch.  I don't think we came up with a name,
>>   but "riscv/gcc-13-perf" seems fine to me.
>> * Regularly rebase the branch on the GCC-13 release branch.
>> * Only accept backports that have landed on trunk.
>
> I'm a bit concerned about how distributions are supposed to handle this.
>
> I can see riscv enthusiasts asking us to package the vendor branch -
> which presumably won't get automatic snapshots created, so that's a bit
> more manual work already. But supposing we switched to it entirely for
> riscv, that might be ok. But what if there's also users who want the
> conservative setup?
>
> This feels (not to be a downer, sorry!) like a mess in the making
> from the distribution perspective.

No problem, that's why we have these sorts of threads.

> I've got to ask: given riscv isn't yet (as far as I understand), a
> "premier platform" in GCC terms, couldn't you just be more liberal
> with backports for riscv at least up until 13.2, or similar?

We've been pretty liberal about backports, but there's always some stuff 
that's just too much to for the standard branch.  It's looking like 14 
is shaping up to be a big one because of all the vector work going on, a 
lot of which is likely to touch core GCC code.

> This is also a lot of work for a platform I don't even have access to
> (we have Gentoo developers with riscv hardware, but not sure any of
> it is powerful enough to be regularly testing this in addition to
> the regular branch for riscv). If even a handful of other arches started
> doing this, I would be completely overwhelmed with work.
>
> Would this also be a long-term thing or just for 13?

We've essentailly done this for every release, it's just been at the 
RISC-V github.  Ideally we'll stop needing to be special, but given the 
history that might take a while.  The difference here is that we're 
trying to keep this at sourceware intsead of the RISC-V github, but 
that's really just because we've had so many headaches with RVI.

As to whether or not distros ship it: I've always been against distros 
shipping the RISC-V branches, as they're full of stuff that's not 
suitable for normal GCC releases and those policies are in place for a 
reason.  I know there's some vendors who ship them, but that's mostly in 
the embedded space and folks tend to have out of tree patches anyway so 
no big deal.

I treat these as more of a performance preview of the next GCC release, 
a handful of vendors were maintaining those internally.  I'd love if we 
could just use trunk for that, but it's generally not viable because too 
much stuff fails to build.

>> There's a few others that I'd like to add, just based on poking around:
>>
>> * No new regressions for anything that's backported.
>> * Use "git cherry-pick -x" from the trunk commit.
>>
>> We're starting to land some gcc-14 patches already, so I'd prefer to
>> make the branch sooner rather than later.  Unless there's any
>> objections, I'll push what's at
>> github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.
>
> thanks,
> sam

Re: GCC-13 Branch with RISC-V Performance-Related Backports

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 4023 bytes --]


Palmer Dabbelt <palmer@dabbelt.com> writes:

> We talked about this a bit on IRC, but just to reflect it to the
> mailing lists:
>
> On Tue, 18 Apr 2023 05:34:11 PDT (-0700), sam@gentoo.org wrote:
>>
>> Palmer Dabbelt <palmer@dabbelt.com> writes:
>>
>>> Based on some discussions, it looks like a handful of vendors are
>>> planning on maintaining GCC-13 branches that include various
>>> performance-related backports (ie, patches not suitable for the
>>> standard GCC-13 release branch).
>>>
>>> I don't think we'd actually agreed to a set of branch rules, but it
>>> seems like the following were where the discussion ended up:
>>>
>>> * Make a "riscv" vendor branch.  I don't think we came up with a name,
>>>   but "riscv/gcc-13-perf" seems fine to me.
>>> * Regularly rebase the branch on the GCC-13 release branch.
>>> * Only accept backports that have landed on trunk.
>>
>> I'm a bit concerned about how distributions are supposed to handle this.
>>
>> I can see riscv enthusiasts asking us to package the vendor branch -
>> which presumably won't get automatic snapshots created, so that's a bit
>> more manual work already. But supposing we switched to it entirely for
>> riscv, that might be ok. But what if there's also users who want the
>> conservative setup?
>>
>> This feels (not to be a downer, sorry!) like a mess in the making
>> from the distribution perspective.
>
> No problem, that's why we have these sorts of threads.
>
>> I've got to ask: given riscv isn't yet (as far as I understand), a
>> "premier platform" in GCC terms, couldn't you just be more liberal
>> with backports for riscv at least up until 13.2, or similar?
>
> We've been pretty liberal about backports, but there's always some
> stuff that's just too much to for the standard branch.  It's looking
> like 14 is shaping up to be a big one because of all the vector work
> going on, a lot of which is likely to touch core GCC code.
>

Fair point.

>> This is also a lot of work for a platform I don't even have access to
>> (we have Gentoo developers with riscv hardware, but not sure any of
>> it is powerful enough to be regularly testing this in addition to
>> the regular branch for riscv). If even a handful of other arches started
>> doing this, I would be completely overwhelmed with work.
>>
>> Would this also be a long-term thing or just for 13?
>
> We've essentailly done this for every release, it's just been at the
> RISC-V github.  Ideally we'll stop needing to be special, but given
> the history that might take a while.  The difference here is that
> we're trying to keep this at sourceware intsead of the RISC-V github,
> but that's really just because we've had so many headaches with RVI.
>
> As to whether or not distros ship it: I've always been against distros
> shipping the RISC-V branches, as they're full of stuff that's not
> suitable for normal GCC releases and those policies are in place for a
> reason.  I know there's some vendors who ship them, but that's mostly
> in the embedded space and folks tend to have out of tree patches
> anyway so no big deal.
>
> I treat these as more of a performance preview of the next GCC
> release, a handful of vendors were maintaining those internally.  I'd
> love if we could just use trunk for that, but it's generally not
> viable because too much stuff fails to build.

Thanks Palmer, I didn't realise this context - having this to refer to
is enough for me, because if nothing else, if someone asks me about it,
I can cite this :)

That makes sense to me & thank you for explaining!

>
>>> There's a few others that I'd like to add, just based on poking around:
>>>
>>> * No new regressions for anything that's backported.
>>> * Use "git cherry-pick -x" from the trunk commit.
>>>
>>> We're starting to land some gcc-14 patches already, so I'd prefer to
>>> make the branch sooner rather than later.  Unless there's any
>>> objections, I'll push what's at
>>> github.com/palmer-dabbelt/gcc/gcc-13-perf as a vendor branch.
>>
>> thanks,
>> sam

best,
sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]