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 <pal...@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
