This patch is a new version of: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662745.html
> Can you elaborate a bit on that? Rearranging the CFG shouldn't matter > in general and relying on the specific TARGET_SFB_ALU feels overly > specific. > Why does the same register in the if_then_else and interfere with vsetvl? When ce1 pass transforms CFG in the case of the conditional move, it deletes then and else basic blocks and in their place adds the conditional move which uses the same pseudo-register as the original vsetvl. This interferes with vsetvl pass precisely because of the merge policy. Use by non rvv flag limits the cases where merging might still be possible. This patch tries to addresses one such issue. Agreed. I have removed TARGET_SFB_ALU flag from the condition. > BTW Bohan Lei has since fixed a bug regarding non-RVV uses. Does the > situation change with that applied? Repeated the testing for sifive-7-series as well as rocket. The same tests are still effected positively: vsetvlmax-9, vsetvlmax-10, vsetvlmax-11, vsetvlmax-15 on sifive-7-series. 2024-10-2 Dusan Stojkovic <dusan.stojko...@rt-rk.com> PR target/113035 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pre_vsetvl::earliest_fuse_vsetvl_info): New fuse condition. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/vsetvlmax-15.c: Updated scan-assembler-times num parameter. CONFIDENTIALITY: The contents of this e-mail are confidential and intended only for the above addressee(s). If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, copying or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. If you receive this e-mail by mistake, please notify the sender and the systems administrator at straym...@rt-rk.com immediately.