Re: [PATCH V2] RISC-V: Update test expectancies with recent scheduler change

[Jeff Law <jeffreyalaw@gmail.com>]

On 3/12/24 3:56 PM, Edwin Lu wrote:
> Given the recent change with adding the scheduler pipeline descriptions,
> many scan-dump failures emerged. Relax the expected assembler output
> conditions on the affected tests to reduce noise.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Disable scheduling
> 	* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto
> 	* gcc.target/riscv/rvv/base/pr108185-1.c: Update test expectancies
> 	* gcc.target/riscv/rvv/base/pr108185-2.c: Ditto
> 	* gcc.target/riscv/rvv/base/pr108185-3.c: Ditto
> 	* gcc.target/riscv/rvv/base/pr108185-4.c: Ditto
> 	* gcc.target/riscv/rvv/base/pr108185-5.c: Ditto
> 	* gcc.target/riscv/rvv/base/pr108185-6.c: Ditto
> 	* gcc.target/riscv/rvv/base/pr108185-7.c: Ditto
> 	* gcc.target/riscv/rvv/base/vcreate.c: Disable scheduling and update
> 	test expectancies
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-30.c: Disable scheduling
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-31.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: Update test
> 	expectancies
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: Ditto
> 	* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: Ditto
As we discussed last week.  This should go forward as it brings a better 
degree of stability to these tests.  Looking forward to cleaner 
testresults as my tester has been complaining about this stuff for a 
month now :(


And a note for the future.  Let's take this one:

> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c
> index 4c6e88e7eed..46d3b5e98d4 100644
> --- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr108185-1.c
> @@ -60,11 +60,11 @@ test_vbool1_then_vbool64(int8_t * restrict in, int8_t * restrict out) {
>   }
>   
>   /* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m8,\s*ta,\s*ma} 6 } } */
> -/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m4,\s*ta,\s*ma} 1 } } */
> -/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m2,\s*ta,\s*ma} 1 } } */
> -/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m1,\s*ta,\s*ma} 1 } } */
> -/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf2,\s*ta,\s*ma} 1 } } */
> -/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf4,\s*ta,\s*ma} 1 } } */
> -/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf8,\s*ta,\s*ma} 1 } } */
> +/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m4,\s*ta,\s*ma} 2 } } */
> +/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m2,\s*ta,\s*ma} 2 } } */
> +/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*m1,\s*ta,\s*ma} 2 } } */
> +/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf2,\s*ta,\s*ma} 2 } } */
> +/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf4,\s*ta,\s*ma} 2 } } */
> +/* { dg-final { scan-assembler-times {vsetvli\s+[a-x][0-9]+,\s*zero,\s*e8,\s*mf8,\s*ta,\s*ma} 2 } } */
>   /* { dg-final { scan-assembler-times {vlm\.v\s+v[0-9]+,\s*0\([a-x][0-9]+\)} 12 } } */
>   /* { dg-final { scan-assembler-times {vsm\.v\s+v[0-9]+,\s*0\([a-x][0-9]+\)} 12 } } */

This shows an example of how uarch information such as instruction 
latency will affect vset counts.  If someone wanted to test that 
pr108185-1 can drive the counts of each of those vsets to since 
instance, they can certainly #include pr108185-1 and provide suitable dg 
directives to set a specific uarch tuning and appropriate dg-final 
directives to ensure just a single instance of each vset occurs.

I'm not expecting you do to this.  Just making a note if someone really 
wants to use those tests to verify a specific set of vsets on a 
particular uarch.


Jeff