Message ID | 20211101025446.55538-1-guojiufu@linux.ibm.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 063003858427 for <patchwork@sourceware.org>; Mon, 1 Nov 2021 02:55:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 063003858427 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1635735326; bh=clk6o4h/ECIEr8+u1hReq44ztqzexgj/EJYJoVAol7w=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=nFnn8lG4tAu93yYsydweAGHJpLRA7+XfADR1ekmssYqGfvSyTZDHcRviAbHHl8Bof IVLjtCwVNUC1kLcMsZJQzEUoyLD5QmV5Z/8Ht8rnJn/mYgZLODfjOJGY+DjGk9nLv/ TWimAcntJ5HMxK+XG1SyJ1yyTFkFaLIYzV3Lxsoc= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 46D9C3858420 for <gcc-patches@gcc.gnu.org>; Mon, 1 Nov 2021 02:54:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46D9C3858420 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1A12MYsA018904; Mon, 1 Nov 2021 02:54:54 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3c27d9gbe2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Nov 2021 02:54:54 +0000 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1A12SFHK003096; Mon, 1 Nov 2021 02:54:54 GMT Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0a-001b2d01.pphosted.com with ESMTP id 3c27d9gbdv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Nov 2021 02:54:54 +0000 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1A12pUdU014584; Mon, 1 Nov 2021 02:54:52 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma02fra.de.ibm.com with ESMTP id 3c0wp9etac-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Nov 2021 02:54:52 +0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1A12mSZ746137830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 1 Nov 2021 02:48:28 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C672642045; Mon, 1 Nov 2021 02:54:48 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 90CA84203F; Mon, 1 Nov 2021 02:54:47 +0000 (GMT) Received: from pike.rch.stglabs.ibm.com (unknown [9.5.12.127]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 1 Nov 2021 02:54:47 +0000 (GMT) To: gcc-patches@gcc.gnu.org Subject: [PATCH] Check number of iterations for test cases pr101145 Date: Mon, 1 Nov 2021 10:54:46 +0800 Message-Id: <20211101025446.55538-1-guojiufu@linux.ibm.com> X-Mailer: git-send-email 2.17.1 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: pXIwawrLVIGkYxDWo9VRO30M4LPQ3yeb X-Proofpoint-GUID: m_x70tNEO35QyjDkd60T4YbREZV-FAAd X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-31_08,2021-10-29_03,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 lowpriorityscore=0 spamscore=0 clxscore=1015 suspectscore=0 impostorscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111010013 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jiufu Guo <guojiufu@linux.ibm.com> Cc: rguenther@suse.de, segher@kernel.crashing.org, wschmidt@linux.ibm.com, jlaw@tachyum.com, dje.gcc@gmail.com Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
Check number of iterations for test cases pr101145
|
|
Commit Message
Jiufu Guo
Nov. 1, 2021, 2:54 a.m. UTC
PR101145 is supporting if the number of iterations can be calculated for the 'until wrap' condition. Current test cases are checking if the loop can be vectorized, if a loop can be vectorized then the number of interations is known. While it would be better to check the loop's number of iterations directly. This patch updates the test cases accordingly. Bootstrap and regtest pass on ppc,ppc64le and x86_64. Is this ok for trunk? BR, Jiufu gcc/testsuite/ChangeLog: * gcc.dg/vect/pr101145_1.c: Update case. * gcc.dg/vect/pr101145_2.c: Update case. * gcc.dg/vect/pr101145_3.c: Update case. --- gcc/testsuite/gcc.dg/vect/pr101145_1.c | 2 +- gcc/testsuite/gcc.dg/vect/pr101145_2.c | 2 +- gcc/testsuite/gcc.dg/vect/pr101145_3.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
Comments
On Mon, 1 Nov 2021, Jiufu Guo wrote: > PR101145 is supporting if the number of iterations can be calculated > for the 'until wrap' condition. Current test cases are checking if > the loop can be vectorized, if a loop can be vectorized then the number > of interations is known. While it would be better to check the loop's > number of iterations directly. This patch updates the test cases > accordingly. > > Bootstrap and regtest pass on ppc,ppc64le and x86_64. > Is this ok for trunk? Not sure - the motivation was to make the loop vectorizable so a vectorized check is strictly more powerful. What's the problem with the existing test? Richard. > BR, > Jiufu > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/pr101145_1.c: Update case. > * gcc.dg/vect/pr101145_2.c: Update case. > * gcc.dg/vect/pr101145_3.c: Update case. > > --- > gcc/testsuite/gcc.dg/vect/pr101145_1.c | 2 +- > gcc/testsuite/gcc.dg/vect/pr101145_2.c | 2 +- > gcc/testsuite/gcc.dg/vect/pr101145_3.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_1.c b/gcc/testsuite/gcc.dg/vect/pr101145_1.c > index 9332b2c4257..13a89fa6863 100644 > --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c > +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c > @@ -10,4 +10,4 @@ > > #include "pr101145.inc" > > -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ > +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ > diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c > index fa2c6be689a..5265491b98d 100644 > --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c > +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c > @@ -10,4 +10,4 @@ > > #include "pr101145.inc" > > -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ > +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ > diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c > index 9f43c82593f..ffda26cf0bc 100644 > --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c > +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c > @@ -10,4 +10,4 @@ > > #include "pr101145.inc" > > -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ > +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ >
Richard Biener <rguenther@suse.de> writes: > On Mon, 1 Nov 2021, Jiufu Guo wrote: > >> PR101145 is supporting if the number of iterations can be calculated >> for the 'until wrap' condition. Current test cases are checking if >> the loop can be vectorized, if a loop can be vectorized then the number >> of interations is known. While it would be better to check the loop's >> number of iterations directly. This patch updates the test cases >> accordingly. >> >> Bootstrap and regtest pass on ppc,ppc64le and x86_64. >> Is this ok for trunk? > > Not sure - the motivation was to make the loop vectorizable so > a vectorized check is strictly more powerful. What's the problem > with the existing test? Thanks, Richard! The problem of current tests is that some targets do not support vectorization on some types, like "vector(8) unsigned char" on Solaris/SPARC, "vector long long" on Power7: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069 On those targets, the "number of iterations" was calculated for the loops in the test cases, while the loops are not vectorized. The functionality of the patch in PR101145 is to enhance number_of_iterations_cond to calculate the "# of iterations" for the condition like 'while (i-- < n) or (i++ > n)'. When I add cases pr101145*.c, vectorization is used test. At that time, I also think checking vectorization would be more strict, since the goal of computing '# of iterations' is to enable other optimizations, like 'vectorization'. While, I'm wondering it may be better to check the "# of iterations" directly, because the number of iterations is still useful even loops are not vectorized. BR, Jiufu > > Richard. > >> BR, >> Jiufu >> >> gcc/testsuite/ChangeLog: >> >> * gcc.dg/vect/pr101145_1.c: Update case. >> * gcc.dg/vect/pr101145_2.c: Update case. >> * gcc.dg/vect/pr101145_3.c: Update case. >> >> --- >> gcc/testsuite/gcc.dg/vect/pr101145_1.c | 2 +- >> gcc/testsuite/gcc.dg/vect/pr101145_2.c | 2 +- >> gcc/testsuite/gcc.dg/vect/pr101145_3.c | 2 +- >> 3 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_1.c b/gcc/testsuite/gcc.dg/vect/pr101145_1.c >> index 9332b2c4257..13a89fa6863 100644 >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c >> @@ -10,4 +10,4 @@ >> >> #include "pr101145.inc" >> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c >> index fa2c6be689a..5265491b98d 100644 >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c >> @@ -10,4 +10,4 @@ >> >> #include "pr101145.inc" >> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c >> index 9f43c82593f..ffda26cf0bc 100644 >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c >> @@ -10,4 +10,4 @@ >> >> #include "pr101145.inc" >> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ >>
On Wed, 3 Nov 2021, Jiufu Guo wrote: > Richard Biener <rguenther@suse.de> writes: > > > On Mon, 1 Nov 2021, Jiufu Guo wrote: > > > >> PR101145 is supporting if the number of iterations can be calculated > >> for the 'until wrap' condition. Current test cases are checking if > >> the loop can be vectorized, if a loop can be vectorized then the number > >> of interations is known. While it would be better to check the loop's > >> number of iterations directly. This patch updates the test cases > >> accordingly. > >> > >> Bootstrap and regtest pass on ppc,ppc64le and x86_64. > >> Is this ok for trunk? > > > > Not sure - the motivation was to make the loop vectorizable so > > a vectorized check is strictly more powerful. What's the problem > > with the existing test? > > Thanks, Richard! > > The problem of current tests is that some targets do not support > vectorization on some types, like "vector(8) unsigned char" on > Solaris/SPARC, "vector long long" on Power7: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069 > > On those targets, the "number of iterations" was calculated for > the loops in the test cases, while the loops are not vectorized. I see, but can you add appropriate target selectors for the vectorization then and keep those scans? I'm not sure why you return the final IV value from the functions rather than testing correct data in a[], that will complicate selecting the targets that can vectorize things. There is vect_char_add and vect_long_long you could require in addition to vect_int. > The functionality of the patch in PR101145 is to enhance > number_of_iterations_cond to calculate the "# of iterations" for > the condition like 'while (i-- < n) or (i++ > n)'. > When I add cases pr101145*.c, vectorization is used test. At that > time, I also think checking vectorization would be more strict, > since the goal of computing '# of iterations' is to enable other > optimizations, like 'vectorization'. > > While, I'm wondering it may be better to check the "# of iterations" > directly, because the number of iterations is still useful even > loops are not vectorized. > > BR, > Jiufu > > > > > Richard. > > > >> BR, > >> Jiufu > >> > >> gcc/testsuite/ChangeLog: > >> > >> * gcc.dg/vect/pr101145_1.c: Update case. > >> * gcc.dg/vect/pr101145_2.c: Update case. > >> * gcc.dg/vect/pr101145_3.c: Update case. > >> > >> --- > >> gcc/testsuite/gcc.dg/vect/pr101145_1.c | 2 +- > >> gcc/testsuite/gcc.dg/vect/pr101145_2.c | 2 +- > >> gcc/testsuite/gcc.dg/vect/pr101145_3.c | 2 +- > >> 3 files changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_1.c b/gcc/testsuite/gcc.dg/vect/pr101145_1.c > >> index 9332b2c4257..13a89fa6863 100644 > >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c > >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c > >> @@ -10,4 +10,4 @@ > >> > >> #include "pr101145.inc" > >> > >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ > >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ > >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c > >> index fa2c6be689a..5265491b98d 100644 > >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c > >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c > >> @@ -10,4 +10,4 @@ > >> > >> #include "pr101145.inc" > >> > >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ > >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ > >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c > >> index 9f43c82593f..ffda26cf0bc 100644 > >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c > >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c > >> @@ -10,4 +10,4 @@ > >> > >> #include "pr101145.inc" > >> > >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ > >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ > >> >
Richard Biener <rguenther@suse.de> writes: > On Wed, 3 Nov 2021, Jiufu Guo wrote: > >> Richard Biener <rguenther@suse.de> writes: >> >> > On Mon, 1 Nov 2021, Jiufu Guo wrote: >> > >> >> PR101145 is supporting if the number of iterations can be calculated >> >> for the 'until wrap' condition. Current test cases are checking if >> >> the loop can be vectorized, if a loop can be vectorized then the number >> >> of interations is known. While it would be better to check the loop's >> >> number of iterations directly. This patch updates the test cases >> >> accordingly. >> >> >> >> Bootstrap and regtest pass on ppc,ppc64le and x86_64. >> >> Is this ok for trunk? >> > >> > Not sure - the motivation was to make the loop vectorizable so >> > a vectorized check is strictly more powerful. What's the problem >> > with the existing test? >> >> Thanks, Richard! >> >> The problem of current tests is that some targets do not support >> vectorization on some types, like "vector(8) unsigned char" on >> Solaris/SPARC, "vector long long" on Power7: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946 >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069 >> >> On those targets, the "number of iterations" was calculated for >> the loops in the test cases, while the loops are not vectorized. > > I see, but can you add appropriate target selectors for the > vectorization then and keep those scans? I'm not sure why you > return the final IV value from the functions rather than > testing correct data in a[], that will complicate selecting the > targets that can vectorize things. There is vect_char_add and > vect_long_long you could require in addition to vect_int. Hi Richard, Thanks a lot for your sugguestion! vect_char_add and vect_long_long would help these cases. I would update accordingly. One small concern: these cases may not be tested on some platform. BR, Jiufu > >> The functionality of the patch in PR101145 is to enhance >> number_of_iterations_cond to calculate the "# of iterations" for >> the condition like 'while (i-- < n) or (i++ > n)'. >> When I add cases pr101145*.c, vectorization is used test. At that >> time, I also think checking vectorization would be more strict, >> since the goal of computing '# of iterations' is to enable other >> optimizations, like 'vectorization'. >> >> While, I'm wondering it may be better to check the "# of iterations" >> directly, because the number of iterations is still useful even >> loops are not vectorized. >> >> BR, >> Jiufu >> >> > >> > Richard. >> > >> >> BR, >> >> Jiufu >> >> >> >> gcc/testsuite/ChangeLog: >> >> >> >> * gcc.dg/vect/pr101145_1.c: Update case. >> >> * gcc.dg/vect/pr101145_2.c: Update case. >> >> * gcc.dg/vect/pr101145_3.c: Update case. >> >> >> >> --- >> >> gcc/testsuite/gcc.dg/vect/pr101145_1.c | 2 +- >> >> gcc/testsuite/gcc.dg/vect/pr101145_2.c | 2 +- >> >> gcc/testsuite/gcc.dg/vect/pr101145_3.c | 2 +- >> >> 3 files changed, 3 insertions(+), 3 deletions(-) >> >> >> >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_1.c b/gcc/testsuite/gcc.dg/vect/pr101145_1.c >> >> index 9332b2c4257..13a89fa6863 100644 >> >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c >> >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c >> >> @@ -10,4 +10,4 @@ >> >> >> >> #include "pr101145.inc" >> >> >> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ >> >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ >> >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c >> >> index fa2c6be689a..5265491b98d 100644 >> >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c >> >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c >> >> @@ -10,4 +10,4 @@ >> >> >> >> #include "pr101145.inc" >> >> >> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ >> >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ >> >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c >> >> index 9f43c82593f..ffda26cf0bc 100644 >> >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c >> >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c >> >> @@ -10,4 +10,4 @@ >> >> >> >> #include "pr101145.inc" >> >> >> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ >> >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ >> >> >>
Richard Biener <rguenther@suse.de> writes: > On Wed, 3 Nov 2021, Jiufu Guo wrote: > >> Richard Biener <rguenther@suse.de> writes: >> >> > On Mon, 1 Nov 2021, Jiufu Guo wrote: >> > >> >> PR101145 is supporting if the number of iterations can be calculated >> >> for the 'until wrap' condition. Current test cases are checking if >> >> the loop can be vectorized, if a loop can be vectorized then the number >> >> of interations is known. While it would be better to check the loop's >> >> number of iterations directly. This patch updates the test cases >> >> accordingly. >> >> >> >> Bootstrap and regtest pass on ppc,ppc64le and x86_64. >> >> Is this ok for trunk? >> > >> > Not sure - the motivation was to make the loop vectorizable so >> > a vectorized check is strictly more powerful. What's the problem >> > with the existing test? >> >> Thanks, Richard! >> >> The problem of current tests is that some targets do not support >> vectorization on some types, like "vector(8) unsigned char" on >> Solaris/SPARC, "vector long long" on Power7: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946 >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069 >> >> On those targets, the "number of iterations" was calculated for >> the loops in the test cases, while the loops are not vectorized. > > I see, but can you add appropriate target selectors for the > vectorization then and keep those scans? I'm not sure why you > return the final IV value from the functions rather than > testing correct data in a[], that will complicate selecting the > targets that can vectorize things. There is vect_char_add and > vect_long_long you could require in addition to vect_int. Thanks Richard, The final IV would be the index of last iteration, test test cases are checking if it is just wrap around max/min of the index type. I updated the patch accordingly. BR, Jiufu -------------------- [PATCH] Update dg-require-effective-target for pr101145 cases For test cases pr101145*.c, some types are not able to be vectorized on some targets. This patch updates dg-require-effective-target according to test cases. gcc/testsuite/ChangeLog: * gcc.dg/vect/pr101145_1.c: Update case. * gcc.dg/vect/pr101145_2.c: Update case. * gcc.dg/vect/pr101145_3.c: Update case. --- gcc/testsuite/gcc.dg/vect/pr101145_1.c | 2 +- gcc/testsuite/gcc.dg/vect/pr101145_2.c | 2 +- gcc/testsuite/gcc.dg/vect/pr101145_3.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_1.c b/gcc/testsuite/gcc.dg/vect/pr101145_1.c index 9332b2c4257..24a9da63e88 100644 --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c @@ -1,4 +1,4 @@ -/* { dg-require-effective-target vect_int } */ +/* { dg-require-effective-target vect_char_add } */ /* { dg-additional-options "-O3" } */ #define TYPE signed char #define MIN -128 diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c index fa2c6be689a..9091f606066 100644 --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c @@ -1,4 +1,4 @@ -/* { dg-require-effective-target vect_int } */ +/* { dg-require-effective-target vect_char_add } */ /* { dg-additional-options "-O3" } */ #define TYPE unsigned char #define MIN 0 diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c index 9f43c82593f..001e5f38a46 100644 --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c @@ -1,4 +1,4 @@ -/* { dg-require-effective-target vect_int } */ +/* { dg-require-effective-target vect_long_long } */ /* { dg-additional-options "-O3" } */ #define TYPE int * #define MIN ((TYPE)0)
On Thu, 4 Nov 2021, Jiufu Guo wrote: > Richard Biener <rguenther@suse.de> writes: > > > On Wed, 3 Nov 2021, Jiufu Guo wrote: > > > >> Richard Biener <rguenther@suse.de> writes: > >> > >> > On Mon, 1 Nov 2021, Jiufu Guo wrote: > >> > > >> >> PR101145 is supporting if the number of iterations can be calculated > >> >> for the 'until wrap' condition. Current test cases are checking if > >> >> the loop can be vectorized, if a loop can be vectorized then the number > >> >> of interations is known. While it would be better to check the loop's > >> >> number of iterations directly. This patch updates the test cases > >> >> accordingly. > >> >> > >> >> Bootstrap and regtest pass on ppc,ppc64le and x86_64. > >> >> Is this ok for trunk? > >> > > >> > Not sure - the motivation was to make the loop vectorizable so > >> > a vectorized check is strictly more powerful. What's the problem > >> > with the existing test? > >> > >> Thanks, Richard! > >> > >> The problem of current tests is that some targets do not support > >> vectorization on some types, like "vector(8) unsigned char" on > >> Solaris/SPARC, "vector long long" on Power7: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946 > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069 > >> > >> On those targets, the "number of iterations" was calculated for > >> the loops in the test cases, while the loops are not vectorized. > > > > I see, but can you add appropriate target selectors for the > > vectorization then and keep those scans? I'm not sure why you > > return the final IV value from the functions rather than > > testing correct data in a[], that will complicate selecting the > > targets that can vectorize things. There is vect_char_add and > > vect_long_long you could require in addition to vect_int. > > Thanks Richard, > > The final IV would be the index of last iteration, test test cases > are checking if it is just wrap around max/min of the index type. > > I updated the patch accordingly. OK. Thanks, Richard. > BR, > Jiufu > > > -------------------- > [PATCH] Update dg-require-effective-target for pr101145 cases > > For test cases pr101145*.c, some types are not able to be > vectorized on some targets. This patch updates > dg-require-effective-target according to test cases. > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/pr101145_1.c: Update case. > * gcc.dg/vect/pr101145_2.c: Update case. > * gcc.dg/vect/pr101145_3.c: Update case. > > --- > gcc/testsuite/gcc.dg/vect/pr101145_1.c | 2 +- > gcc/testsuite/gcc.dg/vect/pr101145_2.c | 2 +- > gcc/testsuite/gcc.dg/vect/pr101145_3.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_1.c b/gcc/testsuite/gcc.dg/vect/pr101145_1.c > index 9332b2c4257..24a9da63e88 100644 > --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c > +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c > @@ -1,4 +1,4 @@ > -/* { dg-require-effective-target vect_int } */ > +/* { dg-require-effective-target vect_char_add } */ > /* { dg-additional-options "-O3" } */ > #define TYPE signed char > #define MIN -128 > diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c > index fa2c6be689a..9091f606066 100644 > --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c > +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c > @@ -1,4 +1,4 @@ > -/* { dg-require-effective-target vect_int } */ > +/* { dg-require-effective-target vect_char_add } */ > /* { dg-additional-options "-O3" } */ > #define TYPE unsigned char > #define MIN 0 > diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c > index 9f43c82593f..001e5f38a46 100644 > --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c > +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c > @@ -1,4 +1,4 @@ > -/* { dg-require-effective-target vect_int } */ > +/* { dg-require-effective-target vect_long_long } */ > /* { dg-additional-options "-O3" } */ > #define TYPE int * > #define MIN ((TYPE)0) >
diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_1.c b/gcc/testsuite/gcc.dg/vect/pr101145_1.c index 9332b2c4257..13a89fa6863 100644 --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c @@ -10,4 +10,4 @@ #include "pr101145.inc" -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c index fa2c6be689a..5265491b98d 100644 --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c @@ -10,4 +10,4 @@ #include "pr101145.inc" -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */ diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c index 9f43c82593f..ffda26cf0bc 100644 --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c @@ -10,4 +10,4 @@ #include "pr101145.inc" -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */ +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2 "vect" } } */