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

[Jeff Law]

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