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 B308F3858D35; Tue, 27 Dec 2022 14:16:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B308F3858D35 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 (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BRDhJki016444; Tue, 27 Dec 2022 14:16:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : mime-version : content-type : content-transfer-encoding; s=pp1; bh=wzGOXi9zMkoAODDsA38uZQFwoQbHZ62WdlSe4B0DLvU=; b=klnA/Smjei7RBvG1pfwZlGHwCiR9y7WPJTRBOD+l3eW6aI1Uazh6LNcVx/faKzUYws31 C3FckSvRonTXrOwhwrjRsurFX7W6gR2zx6DZQR1YU6/d3oOgEKhXBbvwg6C9mh194CoP YqF5ErIJV8T8r6lvOtxbi73F0TPBCVKsHAx903NaLnQdUQn9wonFETNsEPa83xwx6jmp QMeDrpbWsrXgpW6zC8tnpvEHlfXZzPQ8c3Mx2mh+bvW3yHElsXJoSlBWHufBFtgOgpIq Qrm6gBwZ5ap67CFPvHe0travIUp+cZeTamx2RUnvygGvv69jCkU7za9pxOIetj68SLZi Dg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mr1ub8fnp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 14:16:28 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BRDkmN1027879; Tue, 27 Dec 2022 14:16:27 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mr1ub8fn9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 14:16:27 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BRBIBFo013133; Tue, 27 Dec 2022 14:16:26 GMT Received: from smtprelay05.dal12v.mail.ibm.com ([9.208.130.101]) by ppma04wdc.us.ibm.com (PPS) with ESMTPS id 3mns27sd2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 14:16:26 +0000 Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay05.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BREGPho6030040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 27 Dec 2022 14:16:25 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B2B3858057; Tue, 27 Dec 2022 14:16:25 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6ABA358061; Tue, 27 Dec 2022 14:16:25 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTPS; Tue, 27 Dec 2022 14:16:25 +0000 (GMT) From: Jiufu Guo To: Jiufu Guo via Gcc-patches Cc: Segher Boessenkool , Richard Biener , Richard Biener , dje.gcc@gmail.com, linkw@gcc.gnu.org, jeffreyalaw@gmail.com Subject: Re: [PATCH] loading float member of parameter stored via int registers References: <20221223165239.GA25951@gate.crashing.org> <20221223195207.GB25951@gate.crashing.org> <7ek02dft05.fsf@pike.rch.stglabs.ibm.com> Date: Tue, 27 Dec 2022 22:16:23 +0800 In-Reply-To: <7ek02dft05.fsf@pike.rch.stglabs.ibm.com> (Jiufu Guo via Gcc-patches's message of "Tue, 27 Dec 2022 11:03:06 +0800") Message-ID: <7e8ritexu0.fsf@pike.rch.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Ajw3o22tAW0CRfBFz6fQbc5Q_wAJEA4A X-Proofpoint-ORIG-GUID: 27VAdWFVVx1fZhxS6TLF2HIOZewgKceM X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-27_10,2022-12-27_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 spamscore=0 lowpriorityscore=0 phishscore=0 impostorscore=0 mlxscore=0 adultscore=0 priorityscore=1501 suspectscore=0 clxscore=1015 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212270115 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,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: Hi, Jiufu Guo via Gcc-patches writes: > Hi, > > Segher Boessenkool writes: > >> On Fri, Dec 23, 2022 at 08:13:48PM +0100, Richard Biener wrote: >>> > Am 23.12.2022 um 17:55 schrieb Segher Boessenkool : >>> > There are at least six very different kinds of subreg: >>> >=20 >>> > 0) Lvalue subregs. Most archs have no use for it, and it can be >>> > expressed much more clearly and cleanly always. >>> > 1) Subregs of mem. Do not use, deprecated. When old reload goes away >>> > this will go away. >>> > 2) Subregs of hard registers. Do not use, there are much better ways= to >>> > write subregs of a non-zero byte offset, and for zero offset this is >>> > non-canonical RTL. >>> > 3) Bitcast subregs. In principle they go from one mode to another mo= de >>> > of the same size (but read on). >>> > 4) Paradoxical subregs. A concept completely separate from the rest, >>> > different rules for everything, it has to be special cased almost >>> > everywhere, it would be better if it was a separate rtx_code imo. >>> > 5) Finally, normal subregs, taking a contiguous span of bits from some >>> > value. >>> >=20 >>> > Now, it is invalid to have a subreg of a subreg, so a 3) of a 5) is >>> > written as just one subreg, as you say. And a 4) of a 5) is just >>> > invalid afaics (and let's not talk about 0)..2) anymore :-) ) >>> >=20 >>> >> Note whether targets actually support subreg operations needs to be = queried and I=E2=80=99m not sure how subreg with offset validation should w= ork there. >>> >=20 >>> > But 3) is always valid, no? On pseudos > I also has similar question: do we need to query/recog if "SF(SI#0)" is > valid on the target, or it would always work (even through reload)? > I also hit this during debugging on ppc64le: "SF(SI#0)" is valid, > and "SF(DI#4)" is not valid.=20 >>>=20 >>> Yes, but it will eventually result in a spill/reload which is >>> undesirable when we created this from CSE from a load. So I think >>> for CSE we do want to know whether a spill will definitely not >>> occur. >> >> Does it cause reloads though? On any sane backend? If no movsf pattern >> allows integer registers, can things work at all? >> >> Anyway, the normal way to test if some RTL is valid is to just generate >> it (using validate_change) and then do apply_change_group, which then >> cancels the changes if they do not work. CSE already does some of >> this. > validate_change seems ok. Thanks! >> >> (I am doubtful doing any of this in CSE is a good idea fwiw). > Understand your concern! Especially when we need to emit additional > inns in CSE. > While CSE does some similar work. It transforms > "[sf:DI]=3D%x:DI; %y:DI=3D[sf:DI]" to "%y:DI=3D%x:DI". > and "see if a MEM has already been loaded with a widening operation; > if it has, we can use a subreg of that." (only for int modes). > So, it may be acceptable to do this in CSE (maybe still seems > hacking). This maybe works for "DI to DF", because "mode converting subreg:DF(x:DI,0)" is cheaper than "mem load DF([sf:DI])". Then "y:DF=3D[sf:DI]" can be replaced by "y:DF=3Dx:DI#0". While for "subreg:SF(x:SI,0)", in CSE, it may not cheaper. So, it may be doubtful for "convert DI to SF" in CSE. Any comments or suggestions? BR, Jeff (Jiufu) > > Thanks for so great comments! > > BR, > Jeff (Jiufu) > >> >> >> Segher