+CC Greg who might also have some bits in flight here. On 2/23/24 01:23, Li, Pan2 wrote: > > > I would prefer to only keep zvl and scalable or zvl only, since I > > > don't see too much value in specifying a value which different from > > > zvl*b, that's a legacy option used before zvl*b option was introduced, >
+1 > > and the reason to add that is that could used for compatible with > > > clang/LLVM for riscv_rvv_vector_bits attribute I think? > > > > Yes, exactly to be compatible with clang/llvm. Just take zvl is good > enough IMO, and update in v2 once we have alignment. > +1 It seems you would also want to implement feature macro __riscv_v_fixed_vlen which llvm does and downstream projects such as xsimd rely on. > > > > And if we want this (I'm not sure), it really feels like it ought to > defer to gcc-15. > > > But I'd like to CC more RISC-V GCC folks to see the votes. > > > If most of the people don't want this in GCC-14 and defer it to > GCC-15, I won't insist on it. > > > > Sure, let’s wait for a while. > Sure it is late in cycle, but I DO agree to gcc-14 inclusion. And thats because it is related to end user experience: gcc is merely catching up to what llvm already has. Rivos folks working on some downstream projects have brought up this disparity internally. If we don't now, the projects will have to carry that for posterity. For that reason I'd consider this as *fix* category such as a VSETVL fix. P.S. Some of this is captured in PR/112817 and it would be nice to update stuff there too. But to me what is more important under same umbrella, for gcc-14 still, is *attribute riscv_rvv_vector_bits* for VLS codegen (also discussed in same PR/112817). Again this is from same devs for downstream projects complain that gcc is not up to par with llvm there - and this is no longer just syntactic sugar tucked away in a makefile. They actively need #ifdef ugliness in their code to handle llvm vs. gcc. Granted this part of work might (or not) be trivial, specially this late, but I'm just putting it out there for consideration. Thx, -Vineet > > > Pan > > > > *From:*juzhe.zh...@rivai.ai <juzhe.zh...@rivai.ai> > *Sent:* Friday, February 23, 2024 4:38 PM > *To:* jeffreyalaw <jeffreya...@gmail.com>; kito.cheng > <kito.ch...@gmail.com>; Li, Pan2 <pan2...@intel.com> > *Cc:* gcc-patches <gcc-patches@gcc.gnu.org>; Wang, Yanzhang > <yanzhang.w...@intel.com>; Robin Dapp <rdapp....@gmail.com>; palmer > <pal...@rivosinc.com>; vineetg <vine...@rivosinc.com>; Patrick O'Neill > <patr...@rivosinc.com>; Edwin Lu <e...@rivosinc.com> > *Subject:* Re: Re: [PATCH v1] RISC-V: Introduce gcc option > mrvv-vector-bits for RVV > > > > I personally think it's better to has VLS compile option and attribute > in GCC-14. > > Since there are many people porting different libraury > (eigen/highway/xnnpack/openBLAS,...) with VLS feature, > > they test them with Clang. > > > > If we don't support it, we will end up with Clang can compile those > lib but GCC-14 can't which will make RISC-V > > folks think GCC is still pretty far behind than Clang. > > > > Besides, VLS compile option and attribute are pretty safe codes, I > would surprise that it will cause issues on current RVV support. > > > > So, +1 from my side to support VLS compile option and attribute on GCC-14. > > > > But I'd like to CC more RISC-V GCC folks to see the votes. > > If most of the people don't want this in GCC-14 and defer it to > GCC-15, I won't insist on it. > > > > Thanks. > > > > ------------------------------------------------------------------------ > > juzhe.zh...@rivai.ai > > > > *From:* Jeff Law <mailto:jeffreya...@gmail.com> > > *Date:* 2024-02-23 16:29 > > *To:* Kito Cheng <mailto:kito.ch...@gmail.com>; 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> > > *Subject:* Re: [PATCH v1] RISC-V: Introduce gcc option > mrvv-vector-bits for RVV > > > > > > On 2/23/24 01:22, Kito Cheng wrote: > > > I would prefer to only keep zvl and scalable or zvl only, since I > > > don't see too much value in specifying a value which different from > > > zvl*b, that's a legacy option used before zvl*b option was > introduced, > > > and the reason to add that is that could used for compatible with > > > clang/LLVM for riscv_rvv_vector_bits attribute I think? > > And if we want this (I'm not sure), it really feels like it ought to > > defer to gcc-15. > > > > jeff > > > > >
