Thanks Juzhe for explanation, that make more sense to me and sorry for disturbing.
Pan From: juzhe.zh...@rivai.ai <juzhe.zh...@rivai.ai> Sent: Wednesday, June 14, 2023 2:31 PM To: Robin Dapp <rdapp....@gmail.com>; Li, Pan2 <pan2...@intel.com>; gcc-patches <gcc-patches@gcc.gnu.org> Cc: Robin Dapp <rdapp....@gmail.com>; jeffreyalaw <jeffreya...@gmail.com>; Wang, Yanzhang <yanzhang.w...@intel.com>; kito.cheng <kito.ch...@gmail.com> Subject: Re: Re: [PATCH v1] RISC-V: Align the predictor style for define_insn_and_split All failures with (test for excess errors) are not big issues which are created by testcase themselves. For example: FAIL: g++.target/riscv/rvv/base/bug-14.C (test for excess errors) FAIL: g++.target/riscv/rvv/base/bug-9.C (test for excess errors) These 2 failures are because RV32 doesn't have indexed load/store with indexed EEW = 64. Like __riscv_vsuxei64_v_i32mf2 in bug-14.C, this intrinsic is valid in RV64 but invalid in RV32 which is totally correct since according to RVV ISA: The V extension supports all vector load and store instructions (Section Vector Loads and Stores<https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#sec-vector-memory>), except the V extension does not support EEW=64 for index values when XLEN=32. So these 2 failures in RV32 are not the compile's bugs. I have seen: /* { dg-do run { target { { {riscv_vector} && {rv64} } } } } */ in these testcases which can not work to block execution in RV32 (Since such testcase only needs to be tested on RV64). I think this is the issue we need to figure out. So, to conclude: All these failures: === gcc: Unexpected fails for rv32imafdcv ilp32f medlow === FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c -std=c99 -O3 -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for excess errors) FAIL: gcc.target/riscv/rvv/autovec/vmv-imm-run.c -O3 -ftree-vectorize (test for excess errors) === g++: Unexpected fails for rv32imafdcv ilp32f medlow === FAIL: g++.target/riscv/rvv/base/bug-14.C (test for excess errors) FAIL: g++.target/riscv/rvv/base/bug-9.C (test for excess errors) These failures are not compiler's bugs, should be testcase or test framework issues. The only issues related to compiler are these: FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c execution test FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c execution test FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c execution test FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c execution test FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/repeat_run-3.c -std=c99 -O3 -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax execution test These 2 issues I already noticed which should be already fixed by your another patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621610.html Overal, this patch doesn't cause any issues. So, we can go ahead. Thanks. ________________________________ juzhe.zh...@rivai.ai<mailto:juzhe.zh...@rivai.ai> From: Robin Dapp<mailto:rdapp....@gmail.com> Date: 2023-06-14 14:09 To: Li, Pan2<mailto:pan2...@intel.com>; juzhe.zh...@rivai.ai<mailto:juzhe.zh...@rivai.ai>; gcc-patches<mailto:gcc-patches@gcc.gnu.org> CC: rdapp.gcc<mailto:rdapp....@gmail.com>; jeffreyalaw<mailto:jeffreya...@gmail.com>; Wang, Yanzhang<mailto:yanzhang.w...@intel.com>; kito.cheng<mailto:kito.ch...@gmail.com> Subject: Re: [PATCH v1] RISC-V: Align the predictor style for define_insn_and_split Hi Pan, these failures were present before the patch I suppose? They don't look related. Is this what you meant by "the same as upstream"? > FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c -std=c99 -O3 > -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for > excess errors) This one should probably be 64-bit only. Would you mind adjusting it? > FAIL: gcc.target/riscv/rvv/autovec/vmv-imm-run.c -O3 -ftree-vectorize (test > for excess errors) What's happening here? Any details on the output? I don't have a proper sim environment setup yet. How long does the testsuite take with spike? Have you tried qemu as well? Regards Robin
