From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 6A2AA3858D28 for ; Wed, 24 May 2023 15:20:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6A2AA3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=us.ibm.com Received: from pps.filterd (m0353723.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 34OF9Zg3025842; Wed, 24 May 2023 15:20:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=1BUZ2Zp0SGYBFcEgW4R1N5/E1z/r18OZhIEhwG7XQqw=; b=Ugpd+BTn4kcO2Lyz5pxGGzI5zMEuFD/l50XSpw+8JG3HHasdHpedNhuweI5saZuxWW1A NVV3cO6l0z4VGpoaQeqNAd4TrHstc60ch3TBnE6G6pY1JYjVHwkW1ER4crsaIcQERyFn xt0p6+owgX1E9NGu783AoSUlcbijWcl4guoOh0dabazuqvlKVsfzdKZWDi9oBCoCOGGh P4DKnZ+kS5dhUCY07G7qKqPXLyo0o3ETq+aSShBf0D/OFeXj9Fi1mAa9sk2rTgW/3jDC 5uFTdcZpvu2hOW5mFFhsplhtWoabpJPn4bAX5S+HH5qbtadnTyNER9CyjyPTpol5Ihvb ig== Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3qsgnhrnwg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 May 2023 15:20:10 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 34ODePUZ030410; Wed, 24 May 2023 15:20:09 GMT Received: from smtprelay05.dal12v.mail.ibm.com ([9.208.130.101]) by ppma04dal.us.ibm.com (PPS) with ESMTPS id 3qppcda7k3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 May 2023 15:20:09 +0000 Received: from smtpav03.dal12v.mail.ibm.com (smtpav03.dal12v.mail.ibm.com [10.241.53.102]) by smtprelay05.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 34OFK75Q65470968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 May 2023 15:20:07 GMT Received: from smtpav03.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BDE0358056; Wed, 24 May 2023 15:20:07 +0000 (GMT) Received: from smtpav03.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 550C458060; Wed, 24 May 2023 15:20:07 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.31.184]) by smtpav03.dal12v.mail.ibm.com (Postfix) with ESMTP; Wed, 24 May 2023 15:20:07 +0000 (GMT) Message-ID: Subject: Re: [PATCH v2] rs6000: Add buildin for mffscrn instructions From: Carl Love To: "Kewen.Lin" , Peter Bergner Cc: Segher Boessenkool , gcc-patches@gcc.gnu.org, cel@us.ibm.com Date: Wed, 24 May 2023 08:20:06 -0700 In-Reply-To: References: <4f1af7ba04999d0258354b8e6794621ee303ec53.camel@us.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: oU8pDf3VCTnEEdKcGacWx-_KCerYm576 X-Proofpoint-ORIG-GUID: oU8pDf3VCTnEEdKcGacWx-_KCerYm576 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.176.26 definitions=2023-05-24_10,2023-05-24_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 impostorscore=0 priorityscore=1501 clxscore=1015 suspectscore=0 adultscore=0 mlxlogscore=753 malwarescore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2304280000 definitions=main-2305240123 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2023-05-24 at 13:32 +0800, Kewen.Lin wrote: > on 2023/5/24 06:30, Peter Bergner wrote: > > On 5/23/23 12:24 AM, Kewen.Lin wrote: > > > on 2023/5/23 01:31, Carl Love wrote: > > > > The builtins were requested for use in GLibC. As of version > > > > 2.31 they > > > > were added as inline asm. They requested a builtin so the asm > > > > could be > > > > removed. > > > > > > So IMHO we also want the similar support for mffscrn, that is to > > > make > > > use of mffscrn and mffscrni on Power9 and later, but falls back > > > to > > > __builtin_set_fpscr_rn + mffs similar on older platforms. > > > > So __builtin_set_fpscr_rn everything we want (sets the RN bits) and > > uses mffscrn/mffscrni on P9 and later and uses older insns on pre- > > P9. > > The only problem is we don't return the current FPSCR bits, as the > > bif > > is defined to return void. > > Yes. > > > Crazy idea, but could we extend the built-in > > with an overload that returns the FPSCR bits? > > So you agree that we should make this proposed new bif handle pre-P9 > just > like some other existing bifs. :) I think extending it is good and > doable, > but the only concern here is the bif name "__builtin_set_fpscr_rn", > which > matches the existing behavior (only set rounding) but doesn't match > the > proposed extending behavior (set rounding and get some env bits > back). > Maybe it's not a big deal if the documentation clarify it well. Extending the builtin to pre Power 9 is straight forward and I agree would make good sense to do. I am a bit concerned on how to extend __builtin_set_fpscr_rn to add the new functionality. Peter suggests overloading the builtin to either return void or returns FPSCR bits. It is my understanding that the return value for a given builtin had to be the same, i.e. you can't overload the return value. Maybe you can with Bill's new infrastructure? I recall having problems trying to overload the return value in the past and Bill said you couldn't do it. I play with this and see if I can overload the return value. > > > > To be honest, I like > > the __builtin_set_fpscr_rn name better than __builtin_mffscrn[i]. > > +1 > > BR, > Kewen > > > The built-in machinery can see that the usage is expecting a return > > value > > or not and for the pre-P9 code, can skip generating the ending mffs > > if > > we don't want the return value. > > > > Peter > > > >