Thanks. I think we still can continue RVV feature reviewing process in github branch that we have talked about. Such patches that have been reviewed I will still send them to GCC mail list and not to merge right now, we can wait until stage1 is open.
Is it a good idea ? I don't want to make RVV support in GCC stop here since LLVM already has all RVV support and GCC is far behind LLVM for a long time in case of RVV. juzhe.zh...@rivai.ai From: Palmer Dabbelt Date: 2022-11-29 02:02 To: jeffreyalaw CC: juzhe.zhong; gcc-patches; Kito Cheng Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreya...@gmail.com wrote: > > On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote: >> From: Ju-Zhe Zhong <juzhe.zh...@rivai.ai> >> >> gcc/ChangeLog: >> >> * config/riscv/riscv-protos.h (enum vlmul_type): New enum. >> (get_vlmul): New function. >> (get_ratio): Ditto. >> * config/riscv/riscv-v.cc (struct mode_vtype_group): New struct. >> (ENTRY): Adapt for attributes. >> (enum vlmul_type): New enum. >> (get_vlmul): New function. >> (get_ratio): New function. >> * config/riscv/riscv-vector-switch.def (ENTRY): Adapt for >> attributes. >> * config/riscv/riscv.cc (ENTRY): Ditto. >> * config/riscv/vector.md (false,true): Add attributes. > > I'm tempted to push this into the next stage1 given its arrival after > stage1 close, but if the wider RISC-V maintainers want to see it move > forward, I don't object strongly. I'm also on the fence here: the RISC-V V implementation is a huge feature so it's a bit awkward to land it this late in the release, but on the flip side it's a very important feature. It's complicated enough that whatever our first release is will probably be a mess, so I'd prefer to just get that pain out of the way sooner rather than later. There's no V hardware availiable now and nothing concretely announced so any users are probably going to be pretty advanced, but having at least the basics of V in there will allow us to kick the tires on the rest of the stack a lot more easily. There's obviously risk to taking something this late in the process. We don't have anything else that triggers the vectorizer, so I think it should be seperable enough that risk is manageable. Not sure if Kito wants to chim in, though. > I'm curious about the model you're using. Is it going to be something > similar to mode switching? That's the first mental model that comes to > mind. Essentially we determine the VL needed for every chunk of code, > then we do an LCM like algorithm to find the optimal placement points > for VL sets to minimize the number of VL sets across all the paths > through the CFG. Never in a million years would I have expected we'd be > considering reusing that code. > > > Jeff
