[PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[钟居哲]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

 		 && [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

Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[Maciej W. Rozycki]

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

Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[钟居哲]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

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.zhong@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
 

Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[Maciej W. Rozycki]

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

回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[钟居哲]

[-- 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

Re: 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[Maciej W. Rozycki]

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'

[juzhe.zhong]

[-- 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
 

Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[Jeff Law]

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'

[钟居哲]

[-- 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
 

Re: 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[Maciej W. Rozycki]

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'

[juzhe.zhong]

[-- 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
 

Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[Maciej W. Rozycki]

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

Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[钟居哲]

[-- 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
 

Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

[juzhe.zhong]

[-- 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