From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id B5EE23858D1E; Fri, 23 Dec 2022 14:46:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B5EE23858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 2BNEjATY028413; Fri, 23 Dec 2022 08:45:10 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2BNEj9JE028405; Fri, 23 Dec 2022 08:45:09 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 23 Dec 2022 08:45:09 -0600 From: Segher Boessenkool To: Jiufu Guo 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 Message-ID: <20221223144509.GZ25951@gate.crashing.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ev8m2fga3.fsf@pike.rch.stglabs.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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! 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. > 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. 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. Segher