From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 2C7C63858408 for ; Thu, 11 Nov 2021 20:55:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C7C63858408 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1ABKfSjO030186; Thu, 11 Nov 2021 20:55:35 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3c98puacrv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Nov 2021 20:55:34 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1ABKgNL0032603; Thu, 11 Nov 2021 20:55:34 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 3c98puacrm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Nov 2021 20:55:34 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1ABKbKVD008046; Thu, 11 Nov 2021 20:55:33 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma02dal.us.ibm.com with ESMTP id 3c5hbdgr8e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Nov 2021 20:55:33 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1ABKtWSd22741558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Nov 2021 20:55:32 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 81D757805E; Thu, 11 Nov 2021 20:55:32 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 50ACC7805F; Thu, 11 Nov 2021 20:55:32 +0000 (GMT) Received: from [9.211.84.243] (unknown [9.211.84.243]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 11 Nov 2021 20:55:32 +0000 (GMT) Message-ID: Date: Thu, 11 Nov 2021 14:55:31 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Reply-To: wschmidt@linux.ibm.com Subject: Re: [PATCH 16/18] rs6000: Test case adjustments From: Bill Schmidt To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com References: <99b257ea5cb6464d967e11e6ee2d8ee5f59f5321.1630511335.git.wschmidt@linux.ibm.com> <20211105223754.GU614@gate.crashing.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: UaQszg6XR8at4rOGyY-rQrmxG7XFp06P X-Proofpoint-ORIG-GUID: zjlKByIwojuvrVzqaCJql24iJ7LizrsO Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-11_07,2021-11-11_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 clxscore=1015 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111110107 X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2021 20:55:37 -0000 On 11/11/21 2:06 PM, Bill Schmidt wrote: > >>> --- a/gcc/testsuite/gcc.target/powerpc/int_128bit-runnable.c >>> +++ b/gcc/testsuite/gcc.target/powerpc/int_128bit-runnable.c >>> @@ -11,9 +11,9 @@ >>> /* { dg-final { scan-assembler-times {\mvrlq\M} 2 } } */ >>> /* { dg-final { scan-assembler-times {\mvrlqnm\M} 2 } } */ >>> /* { dg-final { scan-assembler-times {\mvrlqmi\M} 2 } } */ >>> -/* { dg-final { scan-assembler-times {\mvcmpequq\M} 16 } } */ >>> -/* { dg-final { scan-assembler-times {\mvcmpgtsq\M} 16 } } */ >>> -/* { dg-final { scan-assembler-times {\mvcmpgtuq\M} 16 } } */ >>> +/* { dg-final { scan-assembler-times {\mvcmpequq\M} 24 } } */ >>> +/* { dg-final { scan-assembler-times {\mvcmpgtsq\M} 26 } } */ >>> +/* { dg-final { scan-assembler-times {\mvcmpgtuq\M} 26 } } */ >>> /* { dg-final { scan-assembler-times {\mvmuloud\M} 1 } } */ >>> /* { dg-final { scan-assembler-times {\mvmulesd\M} 1 } } */ >>> /* { dg-final { scan-assembler-times {\mvmulosd\M} 1 } } */ >> And this? > Again I'm a little sketchy on the details, but I believe this resulted > from some of the vector compares having been previously omitted by > accident from gimple expansion. When I added them in for the new > support, that gave us increased counts here because the code generation > was improved. I'll double-check this one as well to provide a more > certain explanation. Upon review [1], it was the other way around. I removed some of the builtins from early gimple expansion because if we expand those early, we get poor code generation instead of the vector compare instructions we want. As a result we get more matches in this test case. Thanks! Bill [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576526.html > >>> --- a/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-8.c >>> +++ b/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-8.c >>> @@ -126,6 +126,7 @@ void foo (vector signed char *vscr, >>> /* { dg-final { scan-assembler-times "vsubcuw" 4 } } */ >>> /* { dg-final { scan-assembler-times "vsubuwm" 4 } } */ >>> /* { dg-final { scan-assembler-times "vbpermq" 2 } } */ >>> +/* { dg-final { scan-assembler-times "vbpermd" 0 } } */ >>> /* { dg-final { scan-assembler-times "xxleqv" 4 } } */ >>> /* { dg-final { scan-assembler-times "vgbbd" 1 } } */ >>> /* { dg-final { scan-assembler-times "xxlnand" 4 } } */ >> This curious one could have been a separate (obvious) patch. It is a >> bit out-of-place here. > Yeah, bit of a head-scratcher, this. The test case probably went > through a few revisions. I'll test it once more and commit it > separately. > >>> --- a/gcc/testsuite/gcc.target/powerpc/pragma_power8.c >>> +++ b/gcc/testsuite/gcc.target/powerpc/pragma_power8.c >>> @@ -19,6 +19,7 @@ test1 (vector int a, vector int b) >>> #pragma GCC target ("cpu=power7") >>> /* Force a re-read of altivec.h with new cpu target. */ >>> #undef _ALTIVEC_H >>> +#undef _RS6000_VECDEFINES_H >>> #include >> Wow ugly :-) But nothing new here, heh. Best not to look at testcase >> internals too closely, in any case. >> >>> --- a/gcc/testsuite/gcc.target/powerpc/test_mffsl.c >>> +++ b/gcc/testsuite/gcc.target/powerpc/test_mffsl.c >>> @@ -1,5 +1,6 @@ >>> /* { dg-do run { target { powerpc*-*-* } } } */ >>> -/* { dg-options "-O2 -std=c99" } */ >>> +/* { dg-options "-O2 -std=c99 -mcpu=power9" } */ >>> +/* { dg-require-effective-target powerpc_p9vector_ok } */ >>> >>> #ifdef DEBUG >>> #include >> This one is a bug fix as well (and obvious). > Yeah. :-(  Will handle. >>> --- a/gcc/testsuite/gcc.target/powerpc/vsu/vec-all-nez-7.c >>> +++ b/gcc/testsuite/gcc.target/powerpc/vsu/vec-all-nez-7.c >>> @@ -12,5 +12,5 @@ test_all_not_equal_and_not_zero (vector unsigned short *arg1_p, >>> vector unsigned short arg_2 = *arg2_p; >>> >>> return __builtin_vec_vcmpnez_p (__CR6_LT, arg_1, arg_2); >>> - /* { dg-error "'__builtin_altivec_vcmpnezh_p' requires the '-mcpu=power9' option" "" { target *-*-* } .-1 } */ >>> + /* { dg-error "'__builtin_altivec_vcmpnezh_p' requires the '-mpower9-vector' option" "" { target *-*-* } .-1 } */ >>> } >> Hrm. People should not use the -mpower9-vector option (except implied >> by -mcpu=power9, without vectors disabled). How hard is it to give a >> better error message here? > Yeah, agreed, I think I can fix that easily enough. There may be similar > issues with -mpower8-vector as well that should be fixed. > > Thanks for the review! I'll get back on this one soon. > > Bill > >> The obvious bugfixes independent of this series are of course okay for >> trunk, as separate patches, now. But some more work is needed >> elsewhere. >> >> >> Segher