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 3764A3857C5B for ; Thu, 13 Aug 2020 19:48:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3764A3857C5B Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07DJXEW9040096; Thu, 13 Aug 2020 15:48:40 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 32w30qh2mn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 15:48:40 -0400 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 07DJaEZu052638; Thu, 13 Aug 2020 15:48:40 -0400 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 32w30qh2m6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 15:48:39 -0400 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 07DJjBa8015989; Thu, 13 Aug 2020 19:48:39 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma03dal.us.ibm.com with ESMTP id 32skp9qs4s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 19:48:39 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 07DJmZml66388346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Aug 2020 19:48:35 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B66217805E; Thu, 13 Aug 2020 19:48:37 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5D3557805F; Thu, 13 Aug 2020 19:48:37 +0000 (GMT) Received: from Bills-MacBook-Pro.local (unknown [9.163.67.190]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 13 Aug 2020 19:48:37 +0000 (GMT) Reply-To: wschmidt@linux.ibm.com Subject: Re: [PATCH] rs6000, restrict bfloat convert intrinsic to Power 10. Fix BU_P10V macro definitions. To: Carl Love , Segher Boessenkool , dje.gcc@gmail.com, gcc-patches@gcc.gnu.org, Will Schmidt Cc: Bill Schmidt , cel@ibm.com, Peter Bergner References: <52d9124291d13013eb39c960d377ed0db0a282c5.camel@us.ibm.com> <347b09be-1d5e-b6d0-768b-ed044dc1a82e@linux.ibm.com> <20cf1bc3ce038db9e61bb159abed939e18507a98.camel@us.ibm.com> From: Bill Schmidt Message-ID: Date: Thu, 13 Aug 2020 14:48:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20cf1bc3ce038db9e61bb159abed939e18507a98.camel@us.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-13_16:2020-08-13, 2020-08-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0 adultscore=0 clxscore=1015 lowpriorityscore=0 phishscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008130134 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 13 Aug 2020 19:48:42 -0000 On 8/13/20 2:24 PM, Carl Love wrote: > Bill: > > On Thu, 2020-08-13 at 13:38 -0500, Bill Schmidt wrote: >> Hi Carl, >> >> Thanks for cleaning up the consistency issue. The new names and >> related >> adjustments LGTM. >> >> Are there no affected test cases that need adjusting? That >> surprises >> me. For example, didn't __builtin_altivec_xxeval become >> __builtin_vsx_xxeval as a result of this change? Does that not >> appear >> in any test cases? >> >> Thanks, >> >> Bill > In gcc/config/rs6000/rs6000-builtin.def we have > > #define vec_ternarylogic(a, b, c, d) __builtin_vec_xxeval (a, b, c, d) > > The vec_ternarylogic() builtin is used in test files > gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-X.c where X stands > for 1, 2, 3, 4, 5, 6, 7, 8, 9. > > In gcc/confit/rs6000/rs6000-builtin.def > > BU_P10V_VSX_4 (XXEVAL, "xxeval", CONST, xxeval) > > now expands to __builtin_vsx_xxeval as you expect. > > I do not see a test case that uses the old builtin name > __builtin_altivec_xxeval. > > carll@genoa:~/GCC/gcc-mainline-935/gcc/testsuite/gcc.target/powerpc$ > grep -r xxeval * > vec-ternarylogic-0.c:/* { dg-final { scan-assembler {\mxxeval\M} } } */ > vec-ternarylogic-2.c:/* { dg-final { scan-assembler {\mxxeval\M} } } */ > vec-ternarylogic-3.c:/* { dg-final { scan-assembler {\mxxeval\M} } } */ > vec-ternarylogic-4.c:/* { dg-final { scan-assembler {\mxxeval\M} } } */ > vec-ternarylogic-6.c:/* { dg-final { scan-assembler {\mxxeval\M} } } */ > vec-ternarylogic-8.c:/* { dg-final { scan-assembler {\mxxeval\M} } } */ > vec-ternarylogic-9.c:/* { dg-final { scan-assembler {\mxxeval\M} } } */ > carll@genoa:~/GCC/gcc-mainline-935/gcc/testsuite/gcc.target/powerpc$ > > There just seems to be the various tests that are expected to generate > the xxeval instruction. As far as I can see there is no test program that uses the __builtin_altivec_xxeval name. OK, but that was just meant as an example.  We have a fair number of things that changed names, so I was somewhat surprised.  It could be that all of these are likewise hidden via the overload mechanism.  Just checking to be sure. Thanks, Bill > > Carl >