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 8A7EE3858C2C for ; Thu, 9 Sep 2021 22:53:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A7EE3858C2C Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 189Mq3Fh022431; Thu, 9 Sep 2021 18:53:05 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3ayuekg0jd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Sep 2021 18:53:05 -0400 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 189MqCR2023060; Thu, 9 Sep 2021 18:53:04 -0400 Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0b-001b2d01.pphosted.com with ESMTP id 3ayuekg0j5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Sep 2021 18:53:04 -0400 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 189Mm94u014411; Thu, 9 Sep 2021 22:53:04 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma02dal.us.ibm.com with ESMTP id 3aytne15wj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Sep 2021 22:53:03 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 189Mr2eq12321698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Sep 2021 22:53:02 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CAA8D112064; Thu, 9 Sep 2021 22:53:02 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7BDE3112063; Thu, 9 Sep 2021 22:53:02 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.139.21]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTPS; Thu, 9 Sep 2021 22:53:02 +0000 (GMT) Date: Thu, 9 Sep 2021 18:53:01 -0400 From: Michael Meissner To: Richard Biener Cc: Segher Boessenkool , Michael Meissner , GCC Patches , David Edelsohn , Bill Schmidt , Peter Bergner , Will Schmidt Subject: Re: [PATCH] Fix SFmode subreg of DImode and TImode Message-ID: Mail-Followup-To: Michael Meissner , Richard Biener , Segher Boessenkool , GCC Patches , David Edelsohn , Bill Schmidt , Peter Bergner , Will Schmidt References: <20210907230730.GM1583@gate.crashing.org> <20210908170809.GP1583@gate.crashing.org> <5DBC1101-9DD6-48F8-BC25-F4DD354B4D74@gmail.com> <20210908191602.GQ1583@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 8VU9REF6wFyECTHIKETRDLyRnAJkqu0g X-Proofpoint-GUID: 0NiYGunozK49GUfkwdISSyNAXa-uwWCO X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-09_08:2021-09-09, 2021-09-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 suspectscore=0 spamscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001 definitions=main-2109090138 X-Spam-Status: No, score=-4.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: Thu, 09 Sep 2021 22:53:06 -0000 On Thu, Sep 09, 2021 at 08:16:16AM +0200, Richard Biener wrote: > But subreg _is_ bit_cast. What is odd to me is that a "disallowed" subreg > like (subreg:SF (reg:TI ..) 0) magically becomes valid (in terms of > validate_subreg) if you rewrite it as (subreg:SF (subreg:SI (reg:TI ..) 0) 0). > Of course that's nested and invalid but just push the inner subreg to a > new pseudo and the thing becomes valid. Basically I only checked the mode of the SUBREG and the value in SUBREG_REG. I agree (subreg:SF (subreg:SI (reg:TI))) should not be allowed. When I wrote the changes we didn't see SUBREG's as much to access the bottom or top element of a structure that was held in a larger int field. If the patch is not reverted, then we have to deal with this somehow. Such as with my patch that allows (subreg:SF (reg:TI xxx)) and (subreg:SF (reg:DI xxx)). The target hook idea might be too big of a hammer. I would need to play with it to see if there are other losses. On the PowerPC, the problematical subregs only occur when you are moving a register from GPR to a vector/float register or vice versa. If you move a subreg between two GPR registers or two vector/float registers, then you can just do the copy. Part of the issue is for some moves, you need to use a temporary register to convert the results, but of course we have the long standing 'all moves for a mode must be done in a single insn that covers all of the cases'. Then you get into secondary reload territory. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.ibm.com, phone: +1 (978) 899-4797