>> 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.
Ok, let's save these patches and merge them when GCC14 stage1 is open. Would you mind telling me when will stage 1 be open? >> 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. Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework. Actually, me && kito have spent a month on VSETVL PASS and we have made a progress. We have tested it with a lot of testcases, turns out our implementation of VSETVL PASS in GCC has much better codegen than the VSETVL implemented in LLVM side in many different situations because of LCM. I am working on cleaning up the codes and hopefully you will see it soon in the next patch. Thanks juzhe.zh...@rivai.ai From: Jeff Law Date: 2022-11-29 00:44 To: juzhe.zhong; gcc-patches CC: kito.cheng; palmer Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS 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 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
