From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 4CA2E3858425; Fri, 23 Dec 2022 19:14:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4CA2E3858425 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x631.google.com with SMTP id m18so13856880eji.5; Fri, 23 Dec 2022 11:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=Sne+ngzxTKbMjIJK/sxad6DRPBmdSLrO/b1A8Gw8Bmc=; b=IgImir9KjiMUdXUQw4Yp23yuiMox4a4K+s1XGrTTIwlhZmamm9bEZ6cRDUD+JQBOHZ wab2GA3qCwuCmA4AElX1EK3NhHhpLmGH5sJjlGPGFFDuLxVeIiADqEFPOIUN8WpWufc3 Tswd/bh98kwPm7BPKzQ7SKmV7JSKQLy11gSp1XpXX0gtVJtGdHv3+2zMFD51G0/S91YV Ayb+txLOScdlVCdHi7Xxz/iGHsh8NSM4mAQYNTvB/a5nHSI2Yjs4gA2x3mSrIbKB46DG VSrGD8/YyLhQPjqj5ExJ49AylCnDE5KWsyJcQzc2iWjVfYgwBIjRo0Nx54YVMDo6FXyD y/Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Sne+ngzxTKbMjIJK/sxad6DRPBmdSLrO/b1A8Gw8Bmc=; b=0IQDu8S/WCBA/dO30dYXqInzDmblGLFlXdndeGB4f7TKJuuMucgvEOpAtPdlESFR6e 9YWtXw+E9QRoujQpuyPhmwGR9UdlC7bgnFkj/2pagqILEzTy0/SU4Yy9tzdpaWRZOxvT omnzA1XKAMmPX8xhgLov2vp5ym9wRHPuqPvaSvbUZcToIJuVtZVElHdZr3DkbgRPsVN5 rneq88ol6CcXWjkJYkgM4/Nj0nj1S5+FotIk6mjuXsU3G8+sfHqO0YxFqXuHjKsbyyg9 zxGn+L9ib7/ePQtbc1vjgmj8+fhzl2W+rHlCv2PekTsN/AgVsuN1V2BpxXY+6c4GgS26 pMdw== X-Gm-Message-State: AFqh2ko0g8A15eUMLQcDeZ1FIYNzBzakIglA8sTgsuTVcvzmMSSuZcHJ xIDJOmHhF9EC24549pZvQFE= X-Google-Smtp-Source: AMrXdXt0QjMI8vZ0VjGYldhRoet7xTkSOhTT1vbHdViBpcBPstyq/EEcM5t3uSGUItiUBNTt2XKqZQ== X-Received: by 2002:a17:907:970a:b0:7c0:fd1a:79ee with SMTP id jg10-20020a170907970a00b007c0fd1a79eemr12921270ejc.63.1671822840904; Fri, 23 Dec 2022 11:14:00 -0800 (PST) Received: from smtpclient.apple (dynamic-077-009-022-047.77.9.pool.telefonica.de. [77.9.22.47]) by smtp.gmail.com with ESMTPSA id b15-20020aa7c90f000000b0046aa78ecd8asm1794042edt.3.2022.12.23.11.13.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Dec 2022 11:13:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] loading float member of parameter stored via int registers Date: Fri, 23 Dec 2022 20:13:48 +0100 Message-Id: References: <20221223165239.GA25951@gate.crashing.org> Cc: Richard Biener , Jiufu Guo , Jiufu Guo via Gcc-patches , dje.gcc@gmail.com, linkw@gcc.gnu.org, jeffreyalaw@gmail.com In-Reply-To: <20221223165239.GA25951@gate.crashing.org> To: Segher Boessenkool X-Mailer: iPhone Mail (20C65) X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: > Am 23.12.2022 um 17:55 schrieb Segher Boessenkool : >=20 > =EF=BB=BFOn 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. >>>=20 >>> 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. >>=20 >> There=E2=80=99s also a byte offset in subreg, so (subreg:sf (reg:di) 4) i= s a Highpart bitcast. >=20 > 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 queri= ed and I=E2=80=99m not sure how subreg with offset validation should work th= ere. >=20 > But 3) is always valid, no? On pseudos. Yes, but it will eventually result in a spill/reload which is undesirable wh= en we created this from CSE from a load. So I think for CSE we do want to k= now whether a spill will definitely not occur. Richard=20 >=20 > Segher