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 B955E3858D32; Tue, 27 Dec 2022 03:03:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B955E3858D32 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 (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BR2u1H0009240; Tue, 27 Dec 2022 03:03:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding; s=pp1; bh=PPmQfTkT5QKVLgMoNYrl48y8a+xhq36+QhfmvCzmzHg=; b=eEXQ3kKn5D3r9bsSoBnFoytLTdsTA045j0YflJTRsUUGuFJt9MKKOU2QurWzKq25hC+T i+y/Ve0V9BsCWm3HHir3frBFQifzo9RXSFT9WBxLNWWD8XPWBNpdugTOWkwFfvl4J4MG GZt2RK5nmGALUU+mIZZuAqXnnJsRwQTxrutOkYAX/aol5FbQJbMRwAGqS6SL5UgsAZz/ TYFPkxvpfAZNZl0YLXHvPxxughEvBDcAC2T6eC3guA76XD0taQToaZo2KBtVS4pdOga0 61obFK2gTY0TliE94r5yexs5KG7czvfzJACQj4hHdnCycNa13byqNOwq/psFr3vPFY3C OA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mqrbv84m6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 03:03:11 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BR2tlRv008940; Tue, 27 Dec 2022 03:03:11 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mqrbv84kn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 03:03:11 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BQNkSOb011342; Tue, 27 Dec 2022 03:03:09 GMT Received: from smtprelay03.wdc07v.mail.ibm.com ([9.208.129.113]) by ppma05wdc.us.ibm.com (PPS) with ESMTPS id 3mns27ps2m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 03:03:09 +0000 Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay03.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BR338tl13238980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 27 Dec 2022 03:03:08 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2DD7C5805A; Tue, 27 Dec 2022 03:03:08 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D15C458051; Tue, 27 Dec 2022 03:03:07 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTPS; Tue, 27 Dec 2022 03:03:07 +0000 (GMT) From: Jiufu Guo To: Segher Boessenkool Cc: Richard Biener , Richard Biener , Jiufu Guo via Gcc-patches , dje.gcc@gmail.com, linkw@gcc.gnu.org, jeffreyalaw@gmail.com Subject: Re: [PATCH] loading float member of parameter stored via int registers In-Reply-To: <20221223195207.GB25951@gate.crashing.org> (Segher Boessenkool's message of "Fri, 23 Dec 2022 13:52:08 -0600") References: <20221223165239.GA25951@gate.crashing.org> <20221223195207.GB25951@gate.crashing.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Date: Tue, 27 Dec 2022 11:03:06 +0800 Message-ID: <7ek02dft05.fsf@pike.rch.stglabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: pqoUo1LdfiMsOxiJtoaNfzfD5jJJhdrL X-Proofpoint-GUID: sQivK-XbwZl2QdhSAEF3u3YZ5FO0riAP 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-26_18,2022-12-23_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 mlxscore=0 phishscore=0 impostorscore=0 mlxlogscore=988 malwarescore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212270023 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, 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 mode >> > 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 q= ueried and I=E2=80=99m not sure how subreg with offset validation should wo= rk 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). Thanks for so great comments! BR, Jeff (Jiufu) > > > Segher