gcc/config/arch/arch.opt: Option mask gen problem
Hi all, Is it possible, in the arch.opt file, to have GCC generate a bitmask relative to a user-defined variable without an associated name? To illustrate my problem, consider the following option file snippet: ... Variable HOST_WIDE_INT riscv_bitmanip_flags = 0 ... mbmi-zbb Target Mask(BITMANIP_ZBB) Var(riscv_bitmanip_flags) Support the base subset of the Bitmanip extension. ... This generates the following lines in the build/gcc/options.h (marker added by me for clarity): ... #define OPTION_MASK_BITMANIP_ZBB (HOST_WIDE_INT_1U << 0) // #define OPTION_MASK_BITMANIP_ZBC (HOST_WIDE_INT_1U << 1) #define OPTION_MASK_BITMANIP_ZBE (HOST_WIDE_INT_1U << 2) #define OPTION_MASK_BITMANIP_ZBF (HOST_WIDE_INT_1U << 3) #define OPTION_MASK_BITMANIP_ZBM (HOST_WIDE_INT_1U << 4) #define OPTION_MASK_BITMANIP_ZBP (HOST_WIDE_INT_1U << 5) #define OPTION_MASK_BITMANIP_ZBR (HOST_WIDE_INT_1U << 6) #define OPTION_MASK_BITMANIP_ZBS (HOST_WIDE_INT_1U << 7) #define OPTION_MASK_BITMANIP_ZBT (HOST_WIDE_INT_1U << 8) #define MASK_DIV (1U << 0) #define MASK_EXPLICIT_RELOCS (1U << 1) #define MASK_FDIV (1U << 2) #define MASK_SAVE_RESTORE (1U << 3) #define MASK_STRICT_ALIGN (1U << 4) #define MASK_64BIT (1U << 5) #define MASK_ATOMIC (1U << 6) #define MASK_BITMANIP (1U << 7) #define MASK_DOUBLE_FLOAT (1U << 8) #define MASK_HARD_FLOAT (1U << 9) #define MASK_MUL (1U << 10) #define MASK_RVC (1U << 11) #define MASK_RVE (1U << 12) ... But, I don't want the user to be able to pass "-mbmi-zbb" or "-mno-bmi-zbb" on the command line: I only want the generation of the `x_riscv_bitmanip_flags` variable, and the associated bitmasks so that I can use them elsewhere in the backend code. So, I remove the name and description from the entry, like so: ... Target Mask(BITMANIP_ZBB) Var(riscv_bitmanip_flags) ... But now, in the build/gcc/options.h file, the bitmask becomes relative to the generic `x_target_flags` variable: #define OPTION_MASK_BITMANIP_ZBC (HOST_WIDE_INT_1U << 0) #define OPTION_MASK_BITMANIP_ZBE (HOST_WIDE_INT_1U << 1) #define OPTION_MASK_BITMANIP_ZBF (HOST_WIDE_INT_1U << 2) #define OPTION_MASK_BITMANIP_ZBM (HOST_WIDE_INT_1U << 3) #define OPTION_MASK_BITMANIP_ZBP (HOST_WIDE_INT_1U << 4) #define OPTION_MASK_BITMANIP_ZBR (HOST_WIDE_INT_1U << 5) #define OPTION_MASK_BITMANIP_ZBS (HOST_WIDE_INT_1U << 6) #define OPTION_MASK_BITMANIP_ZBT (HOST_WIDE_INT_1U << 7) #define MASK_DIV (1U << 0) #define MASK_EXPLICIT_RELOCS (1U << 1) #define MASK_FDIV (1U << 2) #define MASK_SAVE_RESTORE (1U << 3) #define MASK_STRICT_ALIGN (1U << 4) #define MASK_64BIT (1U << 5) #define MASK_ATOMIC (1U << 6) #define MASK_BITMANIP (1U << 7) #define MASK_DOUBLE_FLOAT (1U << 8) #define MASK_HARD_FLOAT (1U << 9) #define MASK_MUL (1U << 10) #define MASK_RVC (1U << 11) #define MASK_RVE (1U << 12) #define MASK_BITMANIP_ZBB (1U << 13) // Could someone suggest as to a way to get around this problem in the .opt file? Best Regards, Maxim
Lots of FAILs in gcc.target/riscv/rvv/autovec/*
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. However, these tests all pass on master. Presumably the vendor branch failures can all be fixed by cherry picking the right patches from master, but figuring out which ones is probably going to be a slog, so I wanted to ask if there's any desire/point in doing so? Would it be better to just wait until these are automagically fixed by a future rebase? BR, Maxim --- Unique files that trigger failures in vendor branch, but not in master: gcc.target/riscv/rvv/autovec/cond/cond_unary-1.c gcc.target/riscv/rvv/autovec/cond/cond_unary-2.c gcc.target/riscv/rvv/autovec/cond/cond_unary-3.c gcc.target/riscv/rvv/autovec/cond/cond_unary-4.c gcc.target/riscv/rvv/autovec/cond/cond_unary-5.c gcc.target/riscv/rvv/autovec/cond/cond_unary-6.c gcc.target/riscv/rvv/autovec/cond/cond_unary-7.c gcc.target/riscv/rvv/autovec/cond/cond_unary-8.c gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-2.c gcc.target/riscv/rvv/autovec/pr111751.c gcc.target/riscv/rvv/autovec/slp-mask-1.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-1.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-2.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-3.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-4.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-5.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-6.c gcc.target/riscv/rvv/autovec/struct/mask_struct_load-7.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-1.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-2.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-3.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-4.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-5.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-6.c gcc.target/riscv/rvv/autovec/struct/mask_struct_store-7.c gcc.target/riscv/rvv/autovec/struct/struct_vect-10.c gcc.target/riscv/rvv/autovec/struct/struct_vect-11.c gcc.target/riscv/rvv/autovec/struct/struct_vect-12.c gcc.target/riscv/rvv/autovec/struct/struct_vect-13.c gcc.target/riscv/rvv/autovec/struct/struct_vect-14.c gcc.target/riscv/rvv/autovec/struct/struct_vect-15.c gcc.target/riscv/rvv/autovec/struct/struct_vect-16.c gcc.target/riscv/rvv/autovec/struct/struct_vect-17.c gcc.target/riscv/rvv/autovec/struct/struct_vect-18.c gcc.target/riscv/rvv/autovec/struct/struct_vect-1.c gcc.target/riscv/rvv/autovec/struct/struct_vect-2.c gcc.target/riscv/rvv/autovec/struct/struct_vect-3.c gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c gcc.target/riscv/rvv/autovec/struct/struct_vect-5.c gcc.target/riscv/rvv/autovec/struct/struct_vect-6.c gcc.target/riscv/rvv/autovec/struct/struct_vect-7.c gcc.target/riscv/rvv/autovec/struct/struct_vect-8.c gcc.target/riscv/rvv/autovec/struct/struct_vect-9.c gcc.target/riscv/rvv/autovec/vls/cond_not-1.c
Re: Lots of FAILs in gcc.target/riscv/rvv/autovec/*
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 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
