* 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' [not found] <202310100617151969156@rivai.ai> @ 2023-10-09 22:21 ` 钟居哲 2023-10-09 22:38 ` Maciej W. Rozycki 0 siblings, 1 reply; 11+ messages in thread From: 钟居哲 @ 2023-10-09 22:21 UTC (permalink / raw) To: gcc-patches; +Cc: macro, Jeff Law, rdapp.gcc, kito.cheng [-- Attachment #1: Type: text/plain, Size: 2110 bytes --] Btw, could you rebase to the trunk and run regression again? I saw your report 670 FAILs: # of expected passes 187616 # of unexpected failures 672 # of unexpected successes 14 # of expected failures 1436 # of unresolved testcases 615 # of unsupported tests 4731 I am recently working on fixing FAILs of risc-v regression. Your report looks odd. This is my report: # of expected passes 183613 # of unexpected failures 92 # of unexpected successes 12 # of expected failures 1383 # of unresolved testcases 4 # of unsupported tests 4223 This is my report. It should be less than 100 FAILs. juzhe.zhong@rivai.ai 发件人: 钟居哲 发送时间: 2023-10-10 06:17 收件人: gcc-patches 抄送: macro; Jeff Law; rdapp.gcc; kito.cheng 主题: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' && [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 juzhe.zhong@rivai.ai ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-09 22:21 ` 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 钟居哲 @ 2023-10-09 22:38 ` Maciej W. Rozycki 2023-10-10 1:13 ` juzhe.zhong 2023-10-10 10:18 ` 回复: " Maciej W. Rozycki 0 siblings, 2 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2023-10-09 22:38 UTC (permalink / raw) To: 钟居哲; +Cc: gcc-patches, Jeff Law, rdapp.gcc, kito.cheng 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-09 22:38 ` Maciej W. Rozycki @ 2023-10-10 1:13 ` juzhe.zhong 2023-10-10 13:32 ` Jeff Law [not found] ` <ECB692E81C655BA8+4DDCD8AE-E842-4C12-9218-91A95D8658B3@rivai.ai> 2023-10-10 10:18 ` 回复: " Maciej W. Rozycki 1 sibling, 2 replies; 11+ messages in thread From: juzhe.zhong @ 2023-10-10 1:13 UTC (permalink / raw) To: macro; +Cc: gcc-patches, jeffreyalaw, Robin Dapp, Kito.cheng, Richard Biener [-- Attachment #1: Type: text/plain, Size: 1681 bytes --] 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.zhong@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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-10 1:13 ` juzhe.zhong @ 2023-10-10 13:32 ` Jeff Law [not found] ` <ECB692E81C655BA8+4DDCD8AE-E842-4C12-9218-91A95D8658B3@rivai.ai> 1 sibling, 0 replies; 11+ messages in thread From: Jeff Law @ 2023-10-10 13:32 UTC (permalink / raw) To: juzhe.zhong, macro; +Cc: gcc-patches, Robin Dapp, Kito.cheng, Richard Biener On 10/9/23 19:13, juzhe.zhong@rivai.ai wrote: > Oh. I realize this patch increase FAIL that I recently fixed: > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632247.html > <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. So what is the summary on Maciej's patch to enable vec_pack_trunc? ie, is it something we should move forward with as-is, is it superceded by your work in this space or does it need further investigation because of differences in testing methodologies or something else? jeff ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <ECB692E81C655BA8+4DDCD8AE-E842-4C12-9218-91A95D8658B3@rivai.ai>]
* Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' [not found] ` <ECB692E81C655BA8+4DDCD8AE-E842-4C12-9218-91A95D8658B3@rivai.ai> @ 2023-10-10 14:02 ` Jeff Law 2023-10-10 14:07 ` 钟居哲 0 siblings, 1 reply; 11+ messages in thread From: Jeff Law @ 2023-10-10 14:02 UTC (permalink / raw) To: juzhe.zhong; +Cc: macro, gcc-patches, Robin Dapp, Kito.cheng, Richard Biener 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-10 14:02 ` Jeff Law @ 2023-10-10 14:07 ` 钟居哲 0 siblings, 0 replies; 11+ messages in thread From: 钟居哲 @ 2023-10-10 14:07 UTC (permalink / raw) To: Jeff Law; +Cc: macro, gcc-patches, rdapp.gcc, kito.cheng, richard.guenther [-- Attachment #1: Type: text/plain, Size: 1194 bytes --] 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.zhong@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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-09 22:38 ` Maciej W. Rozycki 2023-10-10 1:13 ` juzhe.zhong @ 2023-10-10 10:18 ` Maciej W. Rozycki 2023-10-10 10:20 ` juzhe.zhong 1 sibling, 1 reply; 11+ messages in thread From: Maciej W. Rozycki @ 2023-10-10 10:18 UTC (permalink / raw) To: 钟居哲; +Cc: gcc-patches, Jeff Law, rdapp.gcc, kito.cheng 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-10 10:18 ` 回复: " Maciej W. Rozycki @ 2023-10-10 10:20 ` juzhe.zhong 2023-10-10 21:35 ` Maciej W. Rozycki 0 siblings, 1 reply; 11+ messages in thread From: juzhe.zhong @ 2023-10-10 10:20 UTC (permalink / raw) To: macro; +Cc: gcc-patches, jeffreyalaw, Robin Dapp, Kito.cheng [-- Attachment #1: Type: text/plain, Size: 1363 bytes --] It's weird. Could you give me the FAILs report? juzhe.zhong@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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-10 10:20 ` juzhe.zhong @ 2023-10-10 21:35 ` Maciej W. Rozycki 2023-10-10 22:01 ` 钟居哲 2023-10-11 8:09 ` juzhe.zhong 0 siblings, 2 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2023-10-10 21:35 UTC (permalink / raw) To: juzhe.zhong; +Cc: gcc-patches, jeffreyalaw, Robin Dapp, Kito.cheng On Tue, 10 Oct 2023, juzhe.zhong@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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-10 21:35 ` Maciej W. Rozycki @ 2023-10-10 22:01 ` 钟居哲 2023-10-11 8:09 ` juzhe.zhong 1 sibling, 0 replies; 11+ messages in thread From: 钟居哲 @ 2023-10-10 22:01 UTC (permalink / raw) To: macro; +Cc: gcc-patches, Jeff Law, rdapp.gcc, kito.cheng [-- Attachment #1: Type: text/plain, Size: 1945 bytes --] 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.zhong@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.zhong@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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 2023-10-10 21:35 ` Maciej W. Rozycki 2023-10-10 22:01 ` 钟居哲 @ 2023-10-11 8:09 ` juzhe.zhong 1 sibling, 0 replies; 11+ messages in thread From: juzhe.zhong @ 2023-10-11 8:09 UTC (permalink / raw) To: macro; +Cc: gcc-patches, jeffreyalaw, Robin Dapp, Kito.cheng [-- Attachment #1: Type: text/plain, Size: 2037 bytes --] 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.zhong@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.zhong@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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-10-11 8:09 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <202310100617151969156@rivai.ai> 2023-10-09 22:21 ` 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc' 钟居哲 2023-10-09 22:38 ` Maciej W. Rozycki 2023-10-10 1:13 ` juzhe.zhong 2023-10-10 13:32 ` Jeff Law [not found] ` <ECB692E81C655BA8+4DDCD8AE-E842-4C12-9218-91A95D8658B3@rivai.ai> 2023-10-10 14:02 ` Jeff Law 2023-10-10 14:07 ` 钟居哲 2023-10-10 10:18 ` 回复: " Maciej W. Rozycki 2023-10-10 10:20 ` juzhe.zhong 2023-10-10 21:35 ` Maciej W. Rozycki 2023-10-10 22:01 ` 钟居哲 2023-10-11 8:09 ` juzhe.zhong
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).