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 4C39A385841F for ; Wed, 13 Dec 2023 22:02:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C39A385841F 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4C39A385841F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702504927; cv=none; b=kppyzHPZHkFzTolhKRPm5n6xI5Hl04Vv04IMOkWMxhcGfZ/SJ4O6r/LGrsM82u+jYPMJAA4LpdDhNB3NIk60+rkPjGgz3r6r9IlhMDUrSboa37R1GWGBILPhCrrYrfNxjMrFGHBStdspOh90v6SVraPAU0VBQNp34C4QbvkZ5p0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702504927; c=relaxed/simple; bh=+1lvAmWmjzI+JjRc8cqOSyntB7Pt1sWdTSEZ6F/Jej0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=LXXvzL51hcXksYUODoEyBJWbUM8NU4FYYf612/tXv3FrFMQn2JyFtq9FlBOXewBVpnz2l7b2by9YEkRgx95hbNZeQeW2q5/Don+56znqEmeYke00El/fPz9VV76ATFGO1FzN37dQ2l8lcUfixmkYsaUQnYwgbEGWNL6y0bN6w0w= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3BDKgcge015158; Wed, 13 Dec 2023 22:02:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=SEZ+H3tXsd0pkiHyIFIIsxfDncHT6vJnYXJdLSV7Sjk=; b=UdeLEM0c2dsDqLI/4M3mR7b/6eCAL2z0/xkiUCVdpFlk1+g+ktvNEPLVnMAOesr+BQnt qCE7z59GH11Bwc52eahCQF22vX6zNxVsKZNtWMyWEGFYem1kKuE9bIo9X2rfxnQ1wvzg S1jb0XrbdkFWbQgz0x+lZZEPxSi/1HTInOaMondOSGDhi/nJI232XAodsKw56m9uupt7 mnX/rQaibNybJmFIElwIK1n6MCKNXx/Ou7ApqeM09OCcT1LqR4PKOVzs84MjCcT+FJxJ y3PmpiTogwEhzLBBUrpbEw408ylkvaqnW0E5jUehwejGYxBOXLvzubC51qmd0ev/Qvpf Ng== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3uykvmt20h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Dec 2023 22:02:01 +0000 Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3BDKvABx029260; Wed, 13 Dec 2023 22:02:01 GMT Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3uykvmt1yq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Dec 2023 22:02:01 +0000 Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3BDLX5k2012593; Wed, 13 Dec 2023 22:02:00 GMT Received: from smtprelay01.wdc07v.mail.ibm.com ([172.16.1.68]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3uw3jp468x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Dec 2023 22:02:00 +0000 Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay01.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3BDM1x4U19923516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Dec 2023 22:01:59 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E12D95805F; Wed, 13 Dec 2023 22:01:58 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 71D7F5805A; Wed, 13 Dec 2023 22:01:58 +0000 (GMT) Received: from [9.61.181.199] (unknown [9.61.181.199]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTP; Wed, 13 Dec 2023 22:01:58 +0000 (GMT) Message-ID: <0e75d7ae-b51d-466b-a62e-0a1be94b4424@linux.ibm.com> Date: Wed, 13 Dec 2023 16:01:58 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] rs6000: Disassemble opaque modes using subregs to allow optimizations [PR109116] Content-Language: en-US To: "Kewen.Lin" , Segher Boessenkool Cc: Michael Meissner , GCC Patches , David Edelsohn References: <1f32e2bf-83c2-4664-b7f3-4a6996978a5e@linux.ibm.com> <710b8ada-87de-2947-4050-6a307adff783@linux.ibm.com> From: Peter Bergner In-Reply-To: <710b8ada-87de-2947-4050-6a307adff783@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: z8-MZPt0KU12ClZkNpEj6_L0ZmxgbNve X-Proofpoint-ORIG-GUID: uQipQS_CsMkGkUu2DptzMqXQe1yBBHIQ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-13_14,2023-12-13_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 phishscore=0 mlxscore=0 adultscore=0 spamscore=0 mlxlogscore=727 clxscore=1015 priorityscore=1501 suspectscore=0 impostorscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312130155 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,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 11/24/23 3:28 AM, Kewen.Lin wrote: >> + int regoff = INTVAL (operands[2]) * GET_MODE_SIZE (V16QImode); > > Is it intentional to keep GET_MODE_SIZE (V16QImode) instead of 16? > I think if one day NUM_POLY_INT_COEFFS isn't 1 on rs6000 any more, > we have to add one explicit .to_constant () here. So I prefer this > to use 16 directly, maybe one comment above to indicate what's for > the value 16. I normally don't like hard coding constants in the code, so used GET_MODE_SIZE (V16QImode) as the number of bytes of a vector register, but if that's going to cause an issue in the future, I'm fine using 16. Changed. >> + int regoff = INTVAL (operands[2]) * GET_MODE_SIZE (V16QImode); > > Likewise. Changed. >> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc >> index 5f56c3ed85b..f2efa46c147 100644 >> --- a/gcc/config/rs6000/rs6000.cc >> +++ b/gcc/config/rs6000/rs6000.cc >> @@ -1964,9 +1964,12 @@ rs6000_hard_regno_mode_ok (unsigned int regno, machine_mode mode) >> static bool >> rs6000_modes_tieable_p (machine_mode mode1, machine_mode mode2) >> { >> - if (mode1 == PTImode || mode1 == OOmode || mode1 == XOmode >> - || mode2 == PTImode || mode2 == OOmode || mode2 == XOmode) >> - return mode1 == mode2; >> + if (mode1 == PTImode || mode1 == OOmode || mode1 == XOmode >> + || mode2 == PTImode || mode2 == XOmode) >> + return mode1 == mode2; >> + >> + if (mode2 == OOmode) >> + return ALTIVEC_OR_VSX_VECTOR_MODE (mode1); > > I vaguely remembered that Segher mentioned it's unexpected for opaque > modes to have tieable modes excepting for themselves, but if this is the > only way to get rid of those extra moves, I guess we can special-case > them here. Looking forward to Segher's comments on this part. To be honest, my original patch didn't have this. I think it was Mike who said we want or need this. Mike, why do we want/need this again? That said, the documentation for TARGET_MODES_TIEABLE_P says: This hook returns true if a value of mode mode1 is accessible in mode mode2 without copying. Given OOmode (ie, __vector_pair) under the covers is two consecutive vector registers, and we use them/initialize them with two vectors, then mode1 being a vector mode could be accesible from an OOmode mode2 without copying, meaning we could access it directly from the registers holding mode2. Segher, your input to the above an the subreg portion of the patch in general? Peter