I just checked definition of REG_EQUAL and REG_EQUIV. As you said, REG_EQUIV is more reasonable. Agree with use rtx_equal_p on REG_EQUIV and skip REG_EQUAL. Could you check whether it does fix your issues ?
juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-11-13 17:25 To: juzhe.zh...@rivai.ai; gcc-patches; palmer; kito.cheng; jeffreyalaw CC: rdapp.gcc Subject: Re: [PATCH] RISC-V: vsetvl: Refine REG_EQUAL equality. On 11/13/23 09:25, juzhe.zh...@rivai.ai wrote: > Also, like kito previous remind me: > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635326.html > <https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635326.html> > > I think you should add a dedicated test which with specifying > -march=rv64gcv_zbb, > then scan-assembler-check the correct vsetvl. > > So that we can allow people like me be able to avoid regression of such issue > even if I didn't build toolchain with "zbb". Yes, makes sense. Added. Regarding the use of == instead of rtx_equal_p. Hmm, I'm not sure if pointer equality works. Do we really re-use the exact rtx note for a different insn? When I use note1 == note2 (instead of equal_p) there are regressions: FAIL: gcc.target/riscv/rvv/autovec/vls/dup-1.c -O3 -ftree-vectorize --param riscv-autovec-preference=scalable check-function-bodies foo10 FAIL: gcc.target/riscv/rvv/autovec/vls/dup-2.c -O3 -ftree-vectorize --param riscv-autovec-preference=scalable check-function-bodies foo10 FAIL: gcc.target/riscv/rvv/autovec/vls/dup-3.c -O3 -ftree-vectorize --param riscv-autovec-preference=scalable check-function-bodies foo10 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-102.c -O2 scan-assembler-times vsetvli 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-102.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler-times vsetvli 1 FAIL: gcc.target/riscv/rvv/vsetvl/avl_single-102.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times vsetvli 1 So what we could do instead is rtx_equal_p for REG_EQUIV and skip REG_EQUAL altogether? Regards Robin
