From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id CCE96385840E for ; Fri, 8 Oct 2021 01:04:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CCE96385840E Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19811dxE025100; Thu, 7 Oct 2021 21:04:28 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com with ESMTP id 3bjbyar1yn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Oct 2021 21:04:28 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1980wKVw002774; Fri, 8 Oct 2021 01:04:27 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma01dal.us.ibm.com with ESMTP id 3bef2fqybb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Oct 2021 01:04:27 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19814QLZ43254076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 8 Oct 2021 01:04:26 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 29741112066; Fri, 8 Oct 2021 01:04:26 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BC632112061; Fri, 8 Oct 2021 01:04:25 +0000 (GMT) Received: from li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com (unknown [9.160.40.117]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTPS; Fri, 8 Oct 2021 01:04:25 +0000 (GMT) Date: Thu, 7 Oct 2021 20:04:23 -0500 From: "Paul A. Clarke" To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, wschmidt@linux.ibm.com Message-ID: <20211008010423.GC243632@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com> References: <20210823190310.1679905-1-pc@us.ibm.com> <20210823190310.1679905-2-pc@us.ibm.com> <20211007233906.GQ10333@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211007233906.GQ10333@gate.crashing.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: JtEYDjp7QQiF1BQWIr4PsXJvZ4bbXQ3V X-Proofpoint-ORIG-GUID: JtEYDjp7QQiF1BQWIr4PsXJvZ4bbXQ3V Subject: RE: [PATCH v3 1/6] rs6000: Support SSE4.1 "round" intrinsics X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-07_05,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 suspectscore=0 spamscore=0 impostorscore=0 clxscore=1015 adultscore=0 mlxlogscore=999 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110080004 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 01:04:30 -0000 On Thu, Oct 07, 2021 at 06:39:06PM -0500, Segher Boessenkool wrote: > On Mon, Aug 23, 2021 at 02:03:05PM -0500, Paul A. Clarke wrote: > > No attempt is made to optimize writing the FPSCR (by checking if the new > > value would be the same), other than using lighter weight instructions > > when possible. > > __builtin_set_fpscr_rn makes optimised code (using mtfsb[01]) > automatically, fwiw. > > > Move implementations of _mm_ceil* and _mm_floor* into _mm_round*, and > > convert _mm_ceil* and _mm_floor* into macros. This matches the current > > analogous implementations in config/i386/smmintrin.h. > > Hrm. Using function-like macros is begging for trouble, as usual. But > the x86 version does this, so meh. > > > +extern __inline __m128d > > +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) > > +_mm_round_pd (__m128d __A, int __rounding) > > +{ > > + __v2df __r; > > + union { > > + double __fr; > > + long long __fpscr; > > + } __enables_save, __fpscr_save; > > + > > + if (__rounding & _MM_FROUND_NO_EXC) > > + { > > + /* Save enabled exceptions, disable all exceptions, > > + and preserve the rounding mode. */ > > +#ifdef _ARCH_PWR9 > > + __asm__ __volatile__ ("mffsce %0" : "=f" (__fpscr_save.__fr)); > > The __volatile__ does likely not do what you want. As far as I can see > you do not want one here anyway? > > "volatile" does not order asm wrt fp insns, which you likely *do* want. Reading the GCC docs, it looks like the "volatile" qualifier for "asm" has no effect at all (6.47.1): | The optional volatile qualifier has no effect. All basic asm blocks are | implicitly volatile. So, it could be removed without concern. > > + __v2df __r = { ((__v2df)__B)[0], ((__v2df) __A)[1] }; > > You put spaces after only some casts, btw? Well maybe I found the one > place you did it wrong, heh :-) And you can avoid having so many parens > by making extra variables -- much more readable. I'll fix this. > > + switch (__rounding) > > You do not need any of that __ either. I'm surprised that I don't. A .h file needs to be concerned about the namespace it inherits, no? > > +/* { dg-do run } */ > > +/* { dg-require-effective-target powerpc_vsx_ok } */ > > +/* { dg-options "-O2 -mvsx" } */ > > "dg-do run" requires vsx_hw, not just vsx_ok. Testing on a machine > without VSX (so before p7) would have shown that, but do you have access > to any? This is one of those things we are only told about a year after > it was added, because no one who tests often does that on so old > hardware :-) > > So, okay for trunk (and backports after some burn-in) with that vsx_ok > fixed. That asm needs fixing, but you can do that later. OK. Thanks! PC