Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*
On 11/7/23 21:31, Maxim Blinov wrote: 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. There should be nothing on the vendor branch that is not already on the trunk. If there is, something has gone horribly wrong. The process we've used over there is pretty simple. Start with the gcc-13 branch, then cherry pick risc-v backend & testsuite changes from the trunk as well as limited target independent changes (primarily those which the risc-v backend depends on, or which we know/expect are important for risc-v for one reason or another). 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.) If the vendor branch is generating better code than the trunk then that's an indication that target independent changes on the trunk from the gcc-14 development cycle need some work ;) Just comparing the static number of instructions isn't useful at all IMHO. Now you can get dynamic instructions from various QEMU plugins at which point the data becomes much more interesting -- though you have to be careful interpreting that as well. Jeff
Re: Checks that autotools generated files were re-generated correctly
Hi Martin, On Mon, Nov 06, 2023 at 06:04:48PM +0100, Martin Jambor wrote: > I have inherited Martin Liška's buildbot script that checks that all > sorts of autotools generated files, mainly configure scripts, were > re-generated correctly when appropriate. While the checks are hopefully > useful, they report issues surprisingly often and reporting them feels > especially unproductive. Cool! A small python script cannot replace him of course. But it is nice to get a small virtual mliska :) > Could such checks be added to our server side push hooks so that commits > introducing these breakages would get refused automatically. While the > check might be a bit expensive, it only needs to be run on files > touching the generated files and/or the files these are generated from. So this doesn't just need that script, but also an execution environment that contains the right versions of the autotools. We could install those of course, but running them from a git hook on checkin indeed seems a little expensive. Creating a container with the script and the right versions of all tools might be the best thing. Then the script can be run from a cron job or buildbot. Or even by someone hacking on the build/configure scripts to make sure they are generating with the right tools. builder.sourceware.org already contains various of such containers: https://sourceware.org/cgit/builder/tree/builder/containers https://sourceware.org/cgit/builder/tree/README_containers Friday is Sourceware Open Office hour (#overseers on irc.libera.chat at 18:00 UTC). We could hack something together then and see how to hook it up. Cheers, Mark
Sourceware Open Office, Friday Novemer 10, 18:00 UTC
Every second Friday of the month is the Sourceware Overseers Open Office hour in #overseers on irc.libera.chat from 18:00 till 19:00 UTC. That is this Friday October 10th. This time we will probably focus on integration of builder CI, Full, Try builds and patchwork PreCommit-CI. But please feel free to drop by with any Sourceware services and hosting questions. Or any services that integrates with builder.sourceware.org, patchwork.sourceware.org or snapshots.sourceware.org. For this meeting we will also have a BBB meeting room: https://bbb.sfconservancy.org/b/mar-aom-dmo-fko (But the real discussion will be in the irc channel) If you want to run your own meetings for any Sourceware project you can create your own account at https://bbb.sfconservancy.org/b/signup which we can then activate for you. Note: Anyone is able to join a meeting, accounts are only required to create new meetings. Of course you are welcome to drop into the #overseers channel at any time and we can also be reached through email and bugzilla: https://sourceware.org/mission.html#organization If you aren't already and want to keep up to date on Sourceware infrastructure services then please also subscribe to the overseers mailinglist. https://sourceware.org/mailman/listinfo/overseers We are also on the fediverse these days: https://fosstodon.org/@sourceware The Sourceware Project Leadership Committee also meets once a month to discuss all community input. The committee will set priorities and decide how to spend any funds, negotiate with hardware and service partners, create budgets together with the Conservancy, or decides when a new fundraising campaign is needed. Up till now we have been able to add new services without needing to use any of the collected funds. Our hardware partners have also been very generous with providing extra servers when requested. The current committee includes Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor, Tom Tromey, Jon Turney, Mark J. Wielaard and Elena Zannoni.
