[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: GCC-13 Branch with RISC-V Performance-Related Backports
From:       Sam James via Gcc <gcc () gcc ! gnu ! org>
Date:       2023-04-21 19:51:31
Message-ID: 874jp96mit.fsf () gentoo ! org
[Download RAW message or body]


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

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]