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