Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
Hi, Maciej. I have enable all vectorization test on RVV which is committed: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632598.html But I have added every test with: +|| ([istarget riscv*-*-*] +&& [check_effective_target_riscv_v]) As you said, you think we don't need to add check_effective_target_riscv_v every time. So, feel free to adjust it (remove check_effective_target_riscv_v) and send a patch. But I hope you can adjust each set of tests carefully to make every thing consistent. Thanks. juzhe.zh...@rivai.ai From: Maciej W. Rozycki Date: 2023-10-11 05:35 To: juzhe.zhong CC: gcc-patches; jeffreyalaw; Robin Dapp; Kito.cheng Subject: Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' On Tue, 10 Oct 2023, juzhe.zh...@rivai.ai wrote: > It's weird. Could you give me the FAILs report? I keep forgetting that I have a piece of code in my board description files that makes the testsuite leave output files in place, which helps much when debugging failures (although it's not a perfect solution for test cases like those verified at different optimisation levels where the output filename is reused and consequently subsequent outputs overwrite earlier ones; something to improve perhaps). Unfortunately the presence of output files confuses some test cases and makes them fail; arguably a test case bug. None of the offending test cases are directly related to RISC-V development, so I just ignore the presence of these failures and only focus on regressions and progressions between testsuite runs. Here are fresh results with the testsuite output tree made tidy: === gcc Summary === # of expected passes 194602 # of unexpected failures 145 # of unexpected successes 11 # of expected failures 1631 # of unresolved testcases 120 # of unsupported tests 3828 It probably makes no sense to clutter the mailing list with my FAIL and UNRESOLVED results; I can send them off-list if you find them useful. Maciej
Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
Thanks for investigation. I think the number 145 is reasonable. Even though it is more than my number. I guess the reason you still have more FAILs than me because you are using QEMU (I am using SPIKE), also you need to specify miasligned option to the simulator. For example, for SPIKE, we need --misaligned to the SPIKE. But anyway, no need to send me the FAILs report. I just want to make sure I am not missing some FAILs. juzhe.zh...@rivai.ai From: Maciej W. Rozycki Date: 2023-10-11 05:35 To: juzhe.zhong CC: gcc-patches; jeffreyalaw; Robin Dapp; Kito.cheng Subject: Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' On Tue, 10 Oct 2023, juzhe.zh...@rivai.ai wrote: > It's weird. Could you give me the FAILs report? I keep forgetting that I have a piece of code in my board description files that makes the testsuite leave output files in place, which helps much when debugging failures (although it's not a perfect solution for test cases like those verified at different optimisation levels where the output filename is reused and consequently subsequent outputs overwrite earlier ones; something to improve perhaps). Unfortunately the presence of output files confuses some test cases and makes them fail; arguably a test case bug. None of the offending test cases are directly related to RISC-V development, so I just ignore the presence of these failures and only focus on regressions and progressions between testsuite runs. Here are fresh results with the testsuite output tree made tidy: === gcc Summary === # of expected passes 194602 # of unexpected failures 145 # of unexpected successes 11 # of expected failures 1631 # of unresolved testcases 120 # of unsupported tests 3828 It probably makes no sense to clutter the mailing list with my FAIL and UNRESOLVED results; I can send them off-list if you find them useful. Maciej
Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
On Tue, 10 Oct 2023, juzhe.zh...@rivai.ai wrote: > It's weird. Could you give me the FAILs report? I keep forgetting that I have a piece of code in my board description files that makes the testsuite leave output files in place, which helps much when debugging failures (although it's not a perfect solution for test cases like those verified at different optimisation levels where the output filename is reused and consequently subsequent outputs overwrite earlier ones; something to improve perhaps). Unfortunately the presence of output files confuses some test cases and makes them fail; arguably a test case bug. None of the offending test cases are directly related to RISC-V development, so I just ignore the presence of these failures and only focus on regressions and progressions between testsuite runs. Here are fresh results with the testsuite output tree made tidy: === gcc Summary === # of expected passes194602 # of unexpected failures145 # of unexpected successes 11 # of expected failures 1631 # of unresolved testcases 120 # of unsupported tests 3828 It probably makes no sense to clutter the mailing list with my FAIL and UNRESOLVED results; I can send them off-list if you find them useful. Maciej
Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
Thanks Jeff. I have found multiple dump FAIL issues are related to middle-end. For example: 111721 – RISC-V: Failed to SLP for gather_load in RVV (gnu.org) I have file bugzilla and I will fix them eventually but I am planning to fix the FAILs first which are the testcase issues. Then come back to fix the implementation issues that I have filed bugzilla. So, don't worry. Will keep you posted. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-10-10 22:02 To: juzhe.zhong CC: macro; gcc-patches; Robin Dapp; Kito.cheng; Richard Biener Subject: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' On 10/10/23 07:53, juzhe.zhong wrote: > I am working on it. Currently, we have about 50+ additional FAILs after > enabling vectorization. > > some of them need fixed on middle-end. E.g richard fixed a missed cse > optimization. > > Some need fix on test case. > > I am analyzing each fail one by one. > > I prefer postpone this patch since it will cause some additional fails > and I will handle that eventually after full coverage analysis. OK. We can defer. I just want to make sure we're all know where things stand. jeff
Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
On Tue, 10 Oct 2023, 钟居哲 wrote: > I know you want vect_int to block the test for rv64gc. > But unfortunately it failed. Why? > And I have changed everything to run vect testsuite with "riscv_v". > [PATCH] RISC-V: Enable more tests of "vect" for RVV (gnu.org) > > So to be consistent, plz add "riscv_v". I'll experiment with things here. NB it makes sense to sort targets alphabetically in these feature tests: not only it makes it easier to find whether your target of interest is present in the ever increasing list, but there's less clobber as new targets are added as well, because most time you don't need to fiddle with the test that becomes the second last, which in turn means `git blame' won't show you the noise and save you one step when chasing later on the original commit that has added it. This is why I added my new check in the middle, roughly alphabetically (as the order is a bit messy at present), and you can see how cleaner the resulting change is. Maciej
Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
It's weird. Could you give me the FAILs report?
juzhe.zh...@rivai.ai
From: Maciej W. Rozycki
Date: 2023-10-10 18:18
To: 钟居哲
CC: gcc-patches; Jeff Law; rdapp.gcc; kito.cheng
Subject: Re: 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
On Mon, 9 Oct 2023, Maciej W. Rozycki wrote:
> > Btw, could you rebase to the trunk and run regression again?
>
> Full regression-testing takes roughly 40 hours here and I do not normally
> update the tree midway through my work so as not to add variables and end
> up chasing a moving target, especially with such an unstable state that we
> have ended up with recently with the RISC-V port. Since I'm done with
> this part I can refresh and schedule another run if you are curious as to
> how it looks like from my side. For the C subset alone it'll take less.
After 10 hours I have now got:
=== gcc Summary ===
# of expected passes 194576
# of unexpected failures 600
# of unexpected successes 11
# of expected failures 1631
# of unresolved testcases 120
# of unsupported tests 3828
as at commit cc5033721553 ("Fixes for profile count/probability
maintenance"), which is slightly better, but still far from your 92 FAILs.
NB I ran this testing with `--param=riscv-autovec-preference=scalable'; I
guess I could have mentioned it.
Maciej
Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
Oh. I realize this patch increase FAIL that I recently fixed: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632247.html This fail because RVV doesn't have vec_pack_trunc_optab (Loop vectorizer will failed at first time but succeed at 2nd time), then RVV will dump 4 times FOLD_EXTRACT_LAST instead of 2 (ARM SVE 2 times because they have vec_pack_trunc_optab). I think the root cause of RVV failing at multiple tests of "vect" is that we don't enable vec_pack/vec_unpack/... stuff, we still succeed at vectorizations and we want to enable tests of them (Mostly just using different approach to vectorize it (cause dump FAIL) because of some changing I have done previously in the middle-end). So enabling "vec_pack" for RVV will fix some FAILs but increase some other FAILs. CC to Richi to see more reasonable suggestions. juzhe.zh...@rivai.ai 发件人： Maciej W. Rozycki 发送时间： 2023-10-10 06:38 收件人： 钟居哲 抄送： gcc-patches; Jeff Law; rdapp.gcc; kito.cheng 主题： Re: 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' On Tue, 10 Oct 2023, 钟居哲 wrote: > Btw, could you rebase to the trunk and run regression again? Full regression-testing takes roughly 40 hours here and I do not normally update the tree midway through my work so as not to add variables and end up chasing a moving target, especially with such an unstable state that we have ended up with recently with the RISC-V port. Since I'm done with this part I can refresh and schedule another run if you are curious as to how it looks like from my side. For the C subset alone it'll take less. Maciej
Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
I know you want vect_int to block the test for rv64gc. But unfortunately it failed. And I have changed everything to run vect testsuite with "riscv_v". [PATCH] RISC-V: Enable more tests of "vect" for RVV (gnu.org) So to be consistent, plz add "riscv_v". juzhe.zh...@rivai.ai From: Maciej W. Rozycki Date: 2023-10-10 06:29 To: 钟居哲 CC: gcc-patches; Jeff Law; rdapp.gcc; kito.cheng Subject: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' On Tue, 10 Oct 2023, 钟居哲 wrote: > && [check_effective_target_arm_little_endian]) > || ([istarget mips*-*-*] > && [et-is-effective-target mips_msa]) > + || [istarget riscv*-*-*] > || ([istarget s390*-*-*] > && [check_effective_target_s390_vx]) > || [istarget amdgcn*-*-*] }}] > > You should change it into: > > || ([istarget riscv*-*-*] > && [check_effective_target_riscv_v]) > > Then, these additional FAILs will be removed: > > with no changes (except for intermittent Python failures for C++) with the > remaining testsuites. There are a few of regressions in `-march=rv64gc' > testing: > +FAIL: gcc.dg/vect/pr97678.c scan-tree-dump vect "vectorizing stmts using SLP" > +FAIL: gcc.dg/vect/slp-13-big-array.c scan-tree-dump-times vect "vectorizing > stmts using SLP" 3 > +FAIL: gcc.dg/vect/slp-13.c scan-tree-dump-times vect "vectorizing stmts > using SLP" 3 > +FAIL: gcc.dg/vect/pr97678.c -flto -ffat-lto-objects scan-tree-dump vect > "vectorizing stmts using SLP" > +FAIL: gcc.dg/vect/slp-13-big-array.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorizing stmts using SLP" 3 > +FAIL: gcc.dg/vect/slp-13.c -flto -ffat-lto-objects scan-tree-dump-times > vect "vectorizing stmts using SLP" 3 I explained in the change description why the check for `riscv_v' isn't needed here: the tests mustn't run in the first place, so naturally they cannot fail either. If I missed anything, then please elaborate. Maciej
