Personally I prefer to remove --param=riscv-autovec-preference=none and only allow mrvv-vector-bits, to avoid tricky(maybe) sematic of none preference. However, let’s wait for a while in case there are some comments from others.
Pan From: Kito Cheng <kito.ch...@gmail.com> Sent: Wednesday, February 28, 2024 10:55 PM To: 钟居哲 <juzhe.zh...@rivai.ai> Cc: Li, Pan2 <pan2...@intel.com>; gcc-patches <gcc-patches@gcc.gnu.org>; Wang, Yanzhang <yanzhang.w...@intel.com>; rdapp.gcc <rdapp....@gmail.com>; Jeff Law <jeffreya...@gmail.com> Subject: Re: Re: [PATCH v3] RISC-V: Introduce gcc option mrvv-vector-bits for RVV Hmm, maybe only keep --param=riscv-autovec-preference=none and remove other two if we think that might still useful? But anyway I have no strong opinion to keep that, I mean I am ok to remove whole --param=riscv-autovec-preference. 钟居哲 <juzhe.zh...@rivai.ai<mailto:juzhe.zh...@rivai.ai>> 於 2024年2月28日 週三 21:59 寫道： I think it makes more sense to remove --param=riscv-autovec-preference and add -mrvv-vector-bits.... ________________________________ juzhe.zh...@rivai.ai<mailto:juzhe.zh...@rivai.ai> From: Kito Cheng<mailto:kito.ch...@gmail.com> Date: 2024-02-28 20:56 To: pan2.li<mailto:pan2...@intel.com> CC: gcc-patches<mailto:gcc-patches@gcc.gnu.org>; juzhe.zhong<mailto:juzhe.zh...@rivai.ai>; yanzhang.wang<mailto:yanzhang.w...@intel.com>; rdapp.gcc<mailto:rdapp....@gmail.com>; jeffreyalaw<mailto:jeffreya...@gmail.com> Subject: Re: [PATCH v3] RISC-V: Introduce gcc option mrvv-vector-bits for RVV Take one more look, I think this option should work and integrate with --param=riscv-autovec-preference= since they have similar jobs but slightly different. We have 3 value for --param=riscv-autovec-preference=: none, scalable and fixed-vlmax -mrvv-vector-bits=scalable is work like --param=riscv-autovec-preference=scalable and -mrvv-vector-bits=zvl is work like --param=riscv-autovec-preference=fixed-vlmax. So I think...we need to do some conflict check, like: -mrvv-vector-bits=zvl can't work with --param=riscv-autovec-preference=scalable -mrvv-vector-bits=scalable can't work with --param=riscv-autovec-preference=fixed-vlmax but it may not just alias since there is some useful combinations like: -mrvv-vector-bits=zvl with --param=riscv-autovec-preference=none: NO auto vectorization but intrinsic code still could benefit from the -mrvv-vector-bits=zvl option. -mrvv-vector-bits=scalable with --param=riscv-autovec-preference=none Should still work for VLS code gen, but just disable auto vectorization per the option semantic. However here is something we need some fix, since --param=riscv-autovec-preference=none still disable VLS code gen for now, you can see some example here: https://godbolt.org/z/fMTr3eW7K But I think it's really the right behavior here, this part might need to be fixed in vls_mode_valid_p and some other places. Anyway I think we need to check all use sites with RVV_FIXED_VLMAX and RVV_SCALABLE, and need to make sure all use site of RVV_FIXED_VLMAX also checked with RVV_VECTOR_BITS_ZVL. > -/* Return the VLEN value associated with -march. > +static int > +riscv_convert_vector_bits (int min_vlen) Not sure if we really need this function, it seems it always returns min_vlen? > +{ > + int rvv_bits = 0; > + > + switch (rvv_vector_bits) > + { > + case RVV_VECTOR_BITS_ZVL: > + case RVV_VECTOR_BITS_SCALABLE: > + rvv_bits = min_vlen; > + break; > + default: > + gcc_unreachable (); > + } > + > + return rvv_bits; > +} > + > +/* Return the VLEN value associated with -march and -mwrvv-vector-bits.
