Palmer Dabbelt <pal...@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), 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. >
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
Description: PGP signature
