From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 646F43858D20 for ; Thu, 25 May 2023 03:41:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 646F43858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [10.20.4.52]) by gateway (Coremail) with SMTP id _____8CxpPDn2G5kt7wAAA--.1665S3; Thu, 25 May 2023 11:41:28 +0800 (CST) Received: from [10.20.4.52] (unknown [10.20.4.52]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Cxqrbl2G5kxTx2AA--.65066S2; Thu, 25 May 2023 11:41:25 +0800 (CST) Subject: Re: [PATCH] LoongArch: Fix the problem of structure parameter passing in C++. This structure has empty structure members and less than three floating point members. To: WANG Xuerui , Jason Merrill , Jonathan Wakely Cc: Xi Ruoyao , gcc-patches@gcc.gnu.org, xuchenghua@loongson.cn References: <20230524060407.19181-1-chenglulu@loongson.cn> <2d33bf204b0d59f16df8714123ee812be5754617.camel@xry111.site> <356c3dfd86b82689483fc96f97790909a2e57c47.camel@xry111.site> <59f5839a-bb1e-486a-8c1c-5410ea65360e@xen0n.name> From: Lulu Cheng Message-ID: <25cc069f-8eda-cc20-87f2-8d2e6db575e2@loongson.cn> Date: Thu, 25 May 2023 11:41:25 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <59f5839a-bb1e-486a-8c1c-5410ea65360e@xen0n.name> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8Cxqrbl2G5kxTx2AA--.65066S2 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBjvJXoWxCw4xWryUXw43JF4DCw1DGFg_yoW5trW5pF Z7ta4YyrZ8Cr1kWr4vqr48ZFy5trsxJan8Xr1rtFyvvFZFyr109F4UWF1q9FnrJr4rWr4j qr45J347ur9rArJanT9S1TB71UUUUUJqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bfAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l n4kS14v26r1Y6r17M2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6x ACxx1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1Y6r17McIj6I8E 87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0V AS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwCFI7km 07C267AKxVWUAVWUtwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r 1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWU JVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r 1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUv cSsGvfC2KfnxnUUI43ZEXa7IU88Ma5UUUUU== X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: 在 2023/5/25 上午10:52, WANG Xuerui 写道: > > On 2023/5/25 10:46, Lulu Cheng wrote: >> >> 在 2023/5/25 上午4:15, Jason Merrill 写道: >>> On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches >>> > wrote: >>> >>>     On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote: >>> >>>     > Wang Lei raised some concerns about Itanium C++ ABI, so let's >>>     ask a C++ >>>     > expert here... >>>     > >>>     > Jonathan: AFAIK the standard and the Itanium ABI treats an empty >>>     class >>>     > as size 1 >>> >>>     Only as a complete object, not as a subobject. >>> >>> >>> Also as a data member subobject. >>> >>>     > in order to guarantee unique address, so for the following: >>>     > >>>     > class Empty {}; >>>     > class Test { Empty empty; double a, b; }; >>> >>>     There is no need to have a unique address here, so Test::empty and >>>     Test::a >>>     have the same address. It's a potentially-overlapping subobject. >>> >>>     For the Itanium ABI, sizeof(Test) == 2 * sizeof(double). >>> >>> >>> That would be true if Test::empty were marked [[no_unique_address]], >>> but without that attribute, sizeof(Test) is actually 3 * >>> sizeof(double). >>> >>>     > When we pass "Test" via registers, we may only allocate the >>>     registers >>>     > for Test::a and Test::b, and complete ignore Test::empty because >>>     there >>>     > is no addresses of registers.  Is this correct or not? >>> >>>     I think that's a decision for the loongarch psABI. In principle, >>>     there's no >>>     reason a register has to be used to pass Test::empty, since you >>>     can't read >>>     from it or write to it. >>> >>> >>> Agreed.  The Itanium C++ ABI has nothing to say about how registers >>> are allocated for parameter passing; this is a matter for the psABI. >>> >>> And there is no need for a psABI to allocate a register for >>> Test::empty because it contains no data. >>> >>> In the x86_64 psABI, Test above is passed in memory because of its >>> size ("the size of the aggregate exceeds two eightbytes...").  But >>> >>> struct Test2 { Empty empty; double a; }; >>> >>> is passed in a single floating-point register; the Test2::empty >>> subobject is not passed anywhere, because its eightbyte is >>> classified as NO_CLASS, because there is no actual data there. >> >> >> >>> >>> I know nothing about the LoongArch psABI, but going out of your way >>> to assign a register to an empty class seems like a mistake. >> >> MIPS64 and ARM64 also allocate parameter registers for empty structs. >> https://godbolt.org/z/jT4cY3T5o >> >> Our original intention is not to pass this empty structure member, >> but to make the following two structures treat empty structure members >> >> in the same way in the process of passing parameters. >> >> struct st1 >> { >>      struct empty {} e1; >>      long a; >>      long b; >> }; >> >> struct st2 >> { >>      struct empty {} e1; >>      double f0; >>      double f1; >> }; > > Then shouldn't we try to avoid the extra register in all cases, > instead of wasting one regardless? ;-) https://godbolt.org/z/eK5T3Erbs Compared with the situation of x86-64, if it is necessary not to pass empty structure members, it is difficult to achieve uniform processing.