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
