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 F2CB23858D32; Tue, 27 Dec 2022 02:15:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F2CB23858D32 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 (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BR0ZQMF002470; Tue, 27 Dec 2022 02:15:53 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; s=pp1; bh=xIJXBQfZYSXod7sBt6yY3OjPzeSUJWhDVsWLUsp5JJc=; b=D5odQMP3EBxaQE+4w8FTd23cXXX16sZELKwZAu9/RPJzOShafqHn7+KFY21GIsvOZhxq jl19EwXmQeuWM47M9NkjJTHEd36IeRjXkOBSCeOaFLifjQwk8QW9EvDaJXb52+sGolDW zXBP6UHJfonVl2JCT8XaW5hvJ0Lp7Jb9701LlGQi+nFdlgQWJ10XRYUPoVO2QcYzyDZx +ILCxsaeL+B8r9D9ntB1qKU80NvWhr3ZIyKn4KQUngexJrGiZljMkjvl+yhJcVm1Hqb8 NTFyrIeNx8Ch2d9RTWF6XF78M1iVregp7NSLaMPK432QJL3U9UhO8fH7PRlSXyqZ5LXC 7g== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mqfbyqmu8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 02:15:52 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BR1jVAB003022; Tue, 27 Dec 2022 02:15:52 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mqfbyqmu0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 02:15:52 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BR09ljs013889; Tue, 27 Dec 2022 02:15:51 GMT Received: from smtprelay05.dal12v.mail.ibm.com ([9.208.130.101]) by ppma04dal.us.ibm.com (PPS) with ESMTPS id 3mns27t636-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Dec 2022 02:15:51 +0000 Received: from smtpav03.dal12v.mail.ibm.com (smtpav03.dal12v.mail.ibm.com [10.241.53.102]) by smtprelay05.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BR2FooY61473120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 27 Dec 2022 02:15:50 GMT Received: from smtpav03.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DEB4A58133; Tue, 27 Dec 2022 02:15:49 +0000 (GMT) Received: from smtpav03.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9CFF158129; Tue, 27 Dec 2022 02:15:49 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav03.dal12v.mail.ibm.com (Postfix) with ESMTPS; Tue, 27 Dec 2022 02:15:49 +0000 (GMT) From: Jiufu Guo To: Segher Boessenkool Cc: Jiufu Guo via Gcc-patches , 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: <20221221062736.78036-1-guojiufu@linux.ibm.com> <58beeb5dd65a10b7480f73462da904a4@linux.ibm.com> <7ebknvhkun.fsf@pike.rch.stglabs.ibm.com> <7ev8m2fga3.fsf@pike.rch.stglabs.ibm.com> <20221223144509.GZ25951@gate.crashing.org> Date: Tue, 27 Dec 2022 10:15:45 +0800 In-Reply-To: <20221223144509.GZ25951@gate.crashing.org> (Segher Boessenkool's message of "Fri, 23 Dec 2022 08:45:09 -0600") Message-ID: <7epmc5fv72.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 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: p2R-1ehRtV0L-Yfsz5Fz1dqTP_mOS8nV X-Proofpoint-ORIG-GUID: KCPKdxzYBiol0WpL_7LZy1TNgVr9M0zK 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 clxscore=1015 impostorscore=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 spamscore=0 priorityscore=1501 mlxlogscore=497 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212270015 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: > Hi! > > On Fri, Dec 23, 2022 at 08:36:36PM +0800, Jiufu Guo wrote: >> It seems some limitations there. e.g. 1. "subreg:DF on DI register" >> may not work well on pseudo, > > It is perfectly normal: > A hard register may be accessed in various modes throughout one > function, but each pseudo register is given a natural mode > and is accessed only in that mode. When it is necessary to describe > an access to a pseudo register using a nonnatural mode, a @code{subreg} > expression is used. > > and: > @code{subreg} expressions are used to refer to a register in a machine > mode other than its natural one, or to refer to one register of > a multi-part @code{reg} that actually refers to several registers. > > Each pseudo register has a natural mode. If it is necessary to > operate on it in a different mode, the register must be > enclosed in a @code{subreg}. > > and we even have: > @item hard registers > It is seldom necessary to wrap hard registers in @code{subreg}s; such > registers would normally reduce to a single @code{reg} rtx. This use of > @code{subreg}s is discouraged and may not be supported in the future. > Thanks so much for detailed explaination! >> and 2. to convert high-part:DI to SF, >> a "shift/rotate" is needed, and then we need to "emit shift insn" >> in cse. I may need to update this patch. > > Hrm. The machine insns to do this is just mtvsrd;xscvspdpn, but for > converting the lowpart it is mtvsrws;xscvspdpn (this needs p9 or > later). We should arrive at those patterns, and we should try to not > go via the more expensive formulations with shifts, which don't describe > the hardware well, and which overestimate the cost of it. Yes, understant! > > None of this belongs in generic code at all imo. At expand time it > should be expanded to something that works and can be optimised well, > so not anything with :BLK (which has to be put in memory, something with > unbounded size cannot be put in registers), not anything specifically > tailored to any cpu, something nice and regular. Using a subreg (of a > pseudo!) is the standard way of writing a bitcast. > > So generic code would do a (subreg:SF (reg:SI) 0) to express a 32-bit > integer bitcast to an IEEE SP number, and our machine description should > make it work nicely. Right! So, I'm thinking a way: in generic code, we may generated "shift+(subreg:SF (reg:SI) 0)"; and at somewhere (maybe in combiner), using "mtvsr.." to replace the "shift+subreg". BR, Jeff (Jiufu) > > > Segher