Sure thing. Pan
-----Original Message----- From: Vineet Gupta <vine...@rivosinc.com> Sent: Saturday, March 2, 2024 3:00 AM To: Li, Pan2 <pan2...@intel.com>; Kito Cheng <kito.ch...@gmail.com>; 钟居哲 <juzhe.zh...@rivai.ai> Cc: 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: [PATCH v3] RISC-V: Introduce gcc option mrvv-vector-bits for RVV Hi Pan, On 2/28/24 17:23, Li, Pan2 wrote: > > 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. > We are very interested in this topic. Could you please CC me and Palmer for future versions of the patchset. Thx, -Vineet > > > 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> 於 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 > > > > *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. > > >
