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 CCCA73858C53 for ; Sat, 26 Aug 2023 08:37:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CCCA73858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0353722.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 37Q7tiRm009962; Sat, 26 Aug 2023 08:37:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=XrJtWAJT+QOEEMPJdBSN+83V3wK0oiCoqPrwl65OoEE=; b=IIjW4OewPtlG/ArQVio48MoBEoCjFO3AXx7QAxfCmFOk4uKlxSW0QE3GeKI7Oopjrljx 9sJqcah/vsp1C2OA86aBKWO7DOputAXwoZaO4Rz3mlO4DexLsa0o05QDGo3XLPZqMKNi NA7GqLpz90DBIvJDMV0/3SVAZwExhw398JNTdPAtceOJBfG4nMpw302bVycvNlnUD8vB E/M1Y0NS0QK30nVVlzLVNF7ST2nEiiKi65P5ZZFYjstj6xf2Eit/B1JQpsCyVxeHxkDV GQKaM5hrFBQm+5stQRQyGl0w8SwlF7mdy8U1/rLJmT4egSRLe2yXPXTWwkAWgVxV8YD9 Wg== Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3sqcy00qr1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 26 Aug 2023 08:37:21 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 37Q6PZNO028178; Sat, 26 Aug 2023 08:37:21 GMT Received: from smtprelay06.wdc07v.mail.ibm.com ([172.16.1.73]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3sq9frsgh6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 26 Aug 2023 08:37:21 +0000 Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay06.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 37Q8bJut60948956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 26 Aug 2023 08:37:20 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C60485805E; Sat, 26 Aug 2023 08:37:19 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 59CB458051; Sat, 26 Aug 2023 08:37:19 +0000 (GMT) Received: from cowardly-lion.the-meissners.org (unknown [9.61.167.115]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTPS; Sat, 26 Aug 2023 08:37:19 +0000 (GMT) Date: Sat, 26 Aug 2023 04:37:17 -0400 From: Michael Meissner To: Peter Bergner Cc: Michael Meissner , "Kewen.Lin" , P Jeevitha , GCC Patches , Segher Boessenkool Subject: Re: [PATCH] rs6000: Fix issue in specifying PTImode as an attribute [PR106895] Message-ID: Mail-Followup-To: Michael Meissner , Peter Bergner , "Kewen.Lin" , P Jeevitha , GCC Patches , Segher Boessenkool References: <460cd2bd-7c82-95d8-c58e-f32da70ab2a9@linux.vnet.ibm.com> <9a300552-21a6-cc4c-294d-bec0c6b3739c@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9a300552-21a6-cc4c-294d-bec0c6b3739c@linux.ibm.com> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 2U4c8YRatQZcC1LmOd5SjsviZZSvXC9v X-Proofpoint-GUID: 2U4c8YRatQZcC1LmOd5SjsviZZSvXC9v X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-08-26_06,2023-08-25_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 malwarescore=0 priorityscore=1501 phishscore=0 adultscore=0 clxscore=1015 mlxlogscore=638 suspectscore=0 bulkscore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2308100000 definitions=main-2308260079 X-Spam-Status: No, score=-3.7 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Aug 24, 2023 at 09:19:51PM -0500, Peter Bergner wrote: > On 8/24/23 12:35 PM, Michael Meissner wrote: > > On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote: > >> gcc/ > >> PR target/110411 > >> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields > >> to hold PTImode type. > >> * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node > >> for PTImode type. > > > > It is good as far as it goes, but I suspect we will eventually need to extend > > it. In particular, the reason people need PTImode is they need the even/odd > > register layout. What you've done enables users to declare this value. > > Sure, it could be extended, but that is not what this patch is about. > It's purely to allow the kernel team access to the guaranteed even/odd > register layout for some inline asm code. Any extension would be a > follow-on patch to this. I think we need to get the intended users to try the compiler out, and see if something else happens down the road that we didn't think of. I tend to think of these things like the children's story "If you give a mouse a cookie", which in turn leads to another thing and then another. As I said, I would expect it would be temptimg to start use these types with either 8 byte atomic built-ins, or do masks, etc. In a way, it sort of reminds me of OOmode, where we have this opaque type to load two vectors, but when you start trying to access the two separate registers, you get all sorts of moves, because the compiler underneath the covers doesn't really know it is two registers. In general, I tend that people don't tend to have a full 128-bit integer, but instead you have a structure with two fields, one is the lock and one is the data. So you want to load things together (or do compare/swap, etc.) and then you want to split the parts into 2 pieces, and then later, combine them back into the PTImode container. I really wish we had a constraint that matched the 2nd register in a multi-word register (not an output operation, a constraint so that the register allocator could know that you want to overlap a register). -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com