I see, thanks for clarifying, that makes sense. In that case, what about doing the inverse? I mean, are there unique patches in the vendor branch, and would it be useful to try to upstream them into master? My motivation is to get the best autovectorized code for RISC-V.
I had a go at building the TSVC benchmark (in the llvm-test-suite[1] repository) both with the master and vendor branch gcc, and noticed that the vendor branch gcc generally beats master in generating more vector instructions. If I simply count the number of instances of each vector instruction, the average across all 36 test cases of vendor vs master gcc features the following most prominent differences: - vmv.x.s: 48 vs 0 (+ 48) - vle32.v: 150 vs 50 (+ 100) - vrgather.vv: 61 vs 0 (+ 61) - vslidedown.vi: 61 vs 0 (+ 61) - vse32.v: 472 vs 213 (+ 459) - vmsgtu.vi: 30 vs 0 (+ 30) - vadd.vi: 80 vs 30 (+ 50) - vlm.v: 18 vs 0 (+ 18) - vsm.v: 16 vs 0 (+ 16) - vmv4r.v: 21 vs 7 (+ 14) (For reference, the benchmarks are all between 20k-30k in code size. Built with `-march=rv64imafdcv -O3`.) Ofcourse that doesn't say anything about performance, but would it be possible/fair to say that the vendor branch may still be better than master for generating vectorized code for RISC-V? What's interesting is that there's very little "regression" - I saw only very few cases where the vendor branch removed a vector instruction as compared to master gcc (the most often removed instruction by the vendor branch, as compared to master, is vsetvl/vsetvli.) BR, Maxim [1]: https://github.com/llvm/llvm-test-suite/tree/main/MultiSource/Benchmarks/TSVC On Tue, 7 Nov 2023 at 15:53, Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 11/7/23 05:50, Maxim Blinov wrote: > > Hi all, > > > > I can see about 500 failing tests on the > > vendors/riscv/gcc-13-with-riscv-opts, a mostly-full list at the bottom > > of this email. It's mostly test cases scraping for vector > > instructions. > Correct. There are generic vectorizer changes that would need to be > ported over to that branch to make those tests pass. I looked at this a > few times and ultimately gave up in the rats nest of inter-dependent > patches in the vectorizer. > > > Given the lifetime of that branch is likely nearing its end, I don't > think there's much value left in trying to port those changes over. Any > such effort would likely be better spent nailing down issues on the trunk. > > jeff
