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 56B7E3858D1E; Fri, 23 Dec 2022 16:53:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56B7E3858D1E 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 2BNGqe77000663; Fri, 23 Dec 2022 10:52:40 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2BNGqdxH000660; Fri, 23 Dec 2022 10:52:39 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 23 Dec 2022 10:52:39 -0600 From: Segher Boessenkool To: Richard Biener Cc: Jiufu Guo , 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 Message-ID: <20221223165239.GA25951@gate.crashing.org> References: <20221223144509.GZ25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: On Fri, Dec 23, 2022 at 05:20:09PM +0100, Richard Biener wrote: > > Am 23.12.2022 um 15:48 schrieb Segher Boessenkool : > > 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. > > There’s also a byte offset in subreg, so (subreg:sf (reg:di) 4) is a Highpart bitcast. There are at least six very different kinds of subreg: 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. 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 :-) ) > Note whether targets actually support subreg operations needs to be queried and I’m not sure how subreg with offset validation should work there. But 3) is always valid, no? On pseudos. Segher