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

[Kito Cheng via Gcc]

> > 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.zh...@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 via Gcc]

Palmer Dabbelt  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


signature.asc
Description: PGP signature

Re: "file name" vs "filename"

[Richard Kenner via Gcc]

> A "file name" is the file's name.  It is a property of a file, like the
> inode or size.  The name exists (or not) regardless of whether we know
> what it is.  
> 
> A "filename" is a syntactic element, the thing itself, a string of
> characters.  It is supplied as input or rendered as output.  

For what it's worth, I agree.

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

[Jeff Law via Gcc]

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.zh...@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: RISC-V GCC Patchwork Sync-Up Meeting

[Palmer Dabbelt]

On Mon, 17 Apr 2023 08:08:42 PDT (-0700), Palmer Dabbelt wrote:

The topic of having some sort of RISC-V development meeting has come up
a handful of times, but we never got around to actually setting anything
up.  We've had a patchwork sync meeting for the RISC-V Linux port for a
few months now and it's been super helpful, I figured it be best to just
do something similar for GCC.

The idea is sort of copied from the glibc patchwork meeting, but I've
never been to that before so it's a bit freeform.  Essentially we just
run through the patch backlog and try to make sure everything has been
triaged, which can go a lot quicker in real-time.  We also generally
have time after the triaging to go through and talk about anything
that's of interest.  Like the other meetings this is very much optional
-- in other words, we'll still reflect anything discussed onto the
mailing lists, this is just an additional place to talk.

Here's the Google Meet invite link:

RISC-V GCC Patchwork Sync
Tuesday, April 18 · 7:30 – 8:30am
Google Meet joining info
Video call link: https://meet.google.com/gsf-dchk-ijn

Happy to move to some other service if that's better for folks, this is
just easy to set up on my end.  We can also move to another time if
that's better for folks.  We'll start with every week at 7:30am Pacific.
I've also got a calendar with just this meeting on it, in case it's
easier to have that imported.

https://calendar.google.com/calendar/u/0?cid=Y18xZGUzNDJiN2I4ZmNhNWY4ODg3MWY5NmNkMTkzYmJmOTJkMDNiNmY0NDdlMzk5ZjFlNzA1ZWJjM2Y3Nzg5YTlkQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20

Sorry for the late notice, but I'd forgotten to actually send out an
email.


A handful of us met today and we decided a few things:

We're going to use the sourceware GCC patchwork.  That's shared between 
all GCC targets and there's a lot of outstanding patches for other 
ports, so we're just going to look at patches with "risc-v" in the 
subject (specifically 
).  That 
doesn't mean we're going to stop looking at anything else, just that 
we're going to make sure all those patches get triaged regularly.


To make things manageable, we're going to just bulk archive everything 
from 2022 and earlier.  If there's anything in there folks want looked 
it then please ping it, but the assumption is that everything is 
sufficiently out of date that it at least needs to be rebased.


If that's OK with folks then I'll go archive the old RISC-V patches so 
we can get things triaged more easily.

Don't want to receive messages

[Ruchit Raushan via Gcc]

I don't want to receive further emails.

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

[Palmer Dabbelt]

On Tue, 18 Apr 2023 06:19:07 PDT (-0700), jeffreya...@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.zh...@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), s...@gentoo.org wrote:


Palmer Dabbelt  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: Don't want to receive messages

[Arsen Arsenović via Gcc]

Ruchit Raushan via Gcc  writes:

> I don't want to receive further emails.

Please see https://gcc.gnu.org/mailman/listinfo/gcc
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

I don't want to receive further emails.

[physicsXcosmos via Gcc]

I don't want to receive further emails.

GCC 13 release date

[Vaish, Mayank via Gcc]

[AMD Official Use Only - General]

Hi,

Looking out for GCC 13 release date. GCC Development 
plan only mention about GCC 13 Stage 
4 development.

Please comment on the formal GCC 13 release date.

Thanks.
Mayank

Re: GCC 13 release date

[Sam James via Gcc]

"Vaish, Mayank via Gcc"  writes:

> [AMD Official Use Only - General]
>
> Hi,
>
> Looking out for GCC 13 release date. GCC Development 
> plan only mention about GCC 13 
> Stage 4 development.
>
> Please comment on the formal GCC 13 release date.

I'm just an observer, but RC1 is likely to be today and if nothing goes
badly, GCC 13 will follow a week after that.

This was covered on this mailing list in the last status report a few
days ago: https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html.

>
> Thanks.
> Mayank

thanks,
sam


signature.asc
Description: PGP signature

RE: GCC 13 release date

[Vaish, Mayank via Gcc]

[AMD Official Use Only - General]

Thanks Sam for your prompt response. 

The status message https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html. 
mentions GCC 13.0.1 report. Is there any stable GCC 13.0.0 tag/branch available 
for general use. 

Regards, 
Mayank

-Original Message-
From: Sam James  
Sent: Wednesday, April 19, 2023 11:02 AM
To: Vaish, Mayank 
Cc: gcc@gcc.gnu.org
Subject: Re: GCC 13 release date


"Vaish, Mayank via Gcc"  writes:

> [AMD Official Use Only - General]
>
> Hi,
>
> Looking out for GCC 13 release date. GCC Development 
> plan only mention about GCC 13 
> Stage 4 development.
>
> Please comment on the formal GCC 13 release date.

I'm just an observer, but RC1 is likely to be today and if nothing goes badly, 
GCC 13 will follow a week after that.

This was covered on this mailing list in the last status report a few days ago: 
https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html.

>
> Thanks.
> Mayank

thanks,
sam

Re: GCC 13 release date

[Sam James via Gcc]

"Vaish, Mayank"  writes:

> [AMD Official Use Only - General]
>

Hi Mayank,

> Thanks Sam for your prompt response. 
>
> The status message https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html. 
> mentions GCC 13.0.1 report. Is there any stable GCC 13.0.0 tag/branch 
> available for general use. 

It means that GCC 13.1 will be tagged in a week from the
releases/gcc-13 branch. No GCC 13.0 release will exist.

(It's a 13.0.1 status report because releases/gcc-13 is 13.0.1 (for development)
until it officially becomes 13.1 and is released. 13.0.x would never be 
released.)

I hope that helps.

TL;DR: GCC 13 is coming out in a week, if everything goes OK. And it
will be called '13.1' officially.

>
> Regards, 
> Mayank
>
> -Original Message-
> From: Sam James  
> Sent: Wednesday, April 19, 2023 11:02 AM
> To: Vaish, Mayank 
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC 13 release date
>
>
> "Vaish, Mayank via Gcc"  writes:
>
>> [AMD Official Use Only - General]
>>
>> Hi,
>>
>> Looking out for GCC 13 release date. GCC Development 
>> plan only mention about GCC 13 
>> Stage 4 development.
>>
>> Please comment on the formal GCC 13 release date.
>
> I'm just an observer, but RC1 is likely to be today and if nothing goes 
> badly, GCC 13 will follow a week after that.
>
> This was covered on this mailing list in the last status report a few days 
> ago: https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html.
>
>>
>> Thanks.
>> Mayank
>
> thanks,
> sam



signature.asc
Description: PGP signature

RE: GCC 13 release date

[Vaish, Mayank via Gcc]

[AMD Official Use Only - General]

Thanks Sam. This is clear and helpful. 

Regards, 
Mayank

-Original Message-
From: Sam James  
Sent: Wednesday, April 19, 2023 11:38 AM
To: Vaish, Mayank 
Cc: gcc@gcc.gnu.org
Subject: Re: GCC 13 release date


"Vaish, Mayank"  writes:

> [AMD Official Use Only - General]
>

Hi Mayank,

> Thanks Sam for your prompt response. 
>
> The status message https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html. 
> mentions GCC 13.0.1 report. Is there any stable GCC 13.0.0 tag/branch 
> available for general use. 

It means that GCC 13.1 will be tagged in a week from the
releases/gcc-13 branch. No GCC 13.0 release will exist.

(It's a 13.0.1 status report because releases/gcc-13 is 13.0.1 (for 
development) until it officially becomes 13.1 and is released. 13.0.x would 
never be released.)

I hope that helps.

TL;DR: GCC 13 is coming out in a week, if everything goes OK. And it will be 
called '13.1' officially.

>
> Regards,
> Mayank
>
> -Original Message-
> From: Sam James 
> Sent: Wednesday, April 19, 2023 11:02 AM
> To: Vaish, Mayank 
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC 13 release date
>
>
> "Vaish, Mayank via Gcc"  writes:
>
>> [AMD Official Use Only - General]
>>
>> Hi,
>>
>> Looking out for GCC 13 release date. GCC Development 
>> plan only mention about GCC 13 
>> Stage 4 development.
>>
>> Please comment on the formal GCC 13 release date.
>
> I'm just an observer, but RC1 is likely to be today and if nothing goes 
> badly, GCC 13 will follow a week after that.
>
> This was covered on this mailing list in the last status report a few days 
> ago: https://gcc.gnu.org/pipermail/gcc/2023-April/241140.html.
>
>>
>> Thanks.
>> Mayank
>
> thanks,
> sam