Do you mean change it like this ?
/* { dg-final { scan-tree-dump-times { = \.COND_L?E?N?_?RDIV} 1 "optimized" {
target vect_double_cond_arith } } } */
[email protected]
From: Jeff Law
Date: 2023-10-07 23:09
To: Juzhe-Zhong; gcc-patches
CC: rguenther; rdapp.gcc
Subject: Re: [PATCH] TEST: Fix vect_cond_arith_* dump checks for RVV
On 10/7/23 05:45, Juzhe-Zhong wrote:
> This patch fixes the following dumple FAILs:
> FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_SUB"
> FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
> vect " = \\.COND_ADD"
> FAIL: gcc.dg/vect/vect-cond-arith-2.c scan-tree-dump optimized " =
> \\.COND_SUB"
> FAIL: gcc.dg/vect/vect-cond-arith-2.c scan-tree-dump vect " = \\.COND_ADD"
> FAIL: gcc.dg/vect/vect-cond-arith-4.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_ADD"
> FAIL: gcc.dg/vect/vect-cond-arith-4.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_MUL"
> FAIL: gcc.dg/vect/vect-cond-arith-4.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_RDIV"
> FAIL: gcc.dg/vect/vect-cond-arith-4.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_SUB"
> FAIL: gcc.dg/vect/vect-cond-arith-4.c scan-tree-dump optimized " =
> \\.COND_ADD"
> FAIL: gcc.dg/vect/vect-cond-arith-4.c scan-tree-dump optimized " =
> \\.COND_MUL"
> FAIL: gcc.dg/vect/vect-cond-arith-4.c scan-tree-dump optimized " =
> \\.COND_RDIV"
> FAIL: gcc.dg/vect/vect-cond-arith-4.c scan-tree-dump optimized " =
> \\.COND_SUB"
> FAIL: gcc.dg/vect/vect-cond-arith-5.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_ADD"
> FAIL: gcc.dg/vect/vect-cond-arith-5.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_MUL"
> FAIL: gcc.dg/vect/vect-cond-arith-5.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_RDIV"
> FAIL: gcc.dg/vect/vect-cond-arith-5.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_SUB"
> FAIL: gcc.dg/vect/vect-cond-arith-5.c scan-tree-dump optimized " =
> \\.COND_ADD"
> FAIL: gcc.dg/vect/vect-cond-arith-5.c scan-tree-dump optimized " =
> \\.COND_MUL"
> FAIL: gcc.dg/vect/vect-cond-arith-5.c scan-tree-dump optimized " =
> \\.COND_RDIV"
> FAIL: gcc.dg/vect/vect-cond-arith-5.c scan-tree-dump optimized " =
> \\.COND_SUB"
> FAIL: gcc.dg/vect/vect-cond-arith-6.c -flto -ffat-lto-objects
> scan-tree-dump-times optimized " = \\.COND_ADD" 1
> FAIL: gcc.dg/vect/vect-cond-arith-6.c -flto -ffat-lto-objects
> scan-tree-dump-times optimized " = \\.COND_MUL" 1
> FAIL: gcc.dg/vect/vect-cond-arith-6.c -flto -ffat-lto-objects
> scan-tree-dump-times optimized " = \\.COND_RDIV" 1
> FAIL: gcc.dg/vect/vect-cond-arith-6.c -flto -ffat-lto-objects
> scan-tree-dump-times optimized " = \\.COND_SUB" 1
> FAIL: gcc.dg/vect/vect-cond-arith-6.c scan-tree-dump-times optimized " =
> \\.COND_ADD" 1
> FAIL: gcc.dg/vect/vect-cond-arith-6.c scan-tree-dump-times optimized " =
> \\.COND_MUL" 1
> FAIL: gcc.dg/vect/vect-cond-arith-6.c scan-tree-dump-times optimized " =
> \\.COND_RDIV" 1
> FAIL: gcc.dg/vect/vect-cond-arith-6.c scan-tree-dump-times optimized " =
> \\.COND_SUB" 1
>
> For RVV, the expected dumple IR is COND_LEN_* pattern.
>
> Also, we are still failing at this check:
>
> FAIL: gcc.dg/vect/vect-cond-arith-2.c scan-tree-dump optimized " =
> \\.COND_LEN_SUB"
> FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects scan-tree-dump
> optimized " = \\.COND_LEN_SUB"
>
> Since we have a known bug in GIMPLE_FOLD that Robin is working on it.
>
> @Robin: Plz make sure vect-cond-arith-2.c passes with this patch and your bug
> fix patch.
>
> Ok for trunk ?
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/vect-cond-arith-2.c: Fix dump check for RVV.
> * gcc.dg/vect/vect-cond-arith-4.c: Ditto.
> * gcc.dg/vect/vect-cond-arith-5.c: Ditto.
> * gcc.dg/vect/vect-cond-arith-6.c: Ditto.
Would it make more sense to adjust the regexp so that it matched the
standard form as well as the LEN form? So for example we could have a
regexp that matched COND_ADD and COND_LEN_ADD.
Just wondering if that'll be better from a long term maintenance standpoint.
Jeff
