From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 49D9A3858CDB for ; Thu, 20 Jul 2023 09:22:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 49D9A3858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A92582F4; Thu, 20 Jul 2023 02:23:16 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 20B083F6C4; Thu, 20 Jul 2023 02:22:32 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Jeff Law via Gcc-patches , YunQiang Su , Jeff Law , Eric Botcazou , YunQiang Su , pinskia@gmail.com, ian@airs.com, richard.sandiford@arm.com Cc: Jeff Law via Gcc-patches , YunQiang Su , Jeff Law , Eric Botcazou , YunQiang Su , pinskia@gmail.com, ian@airs.com Subject: Re: [PATCH v2] Store_bit_field_1: Use SUBREG instead of REG if possible References: <20230719041639.2967597-1-yunqiang.su@cipunited.com> <2289802.ElGaqSPkdT@arcturus> <3ad89c88-0cec-c2a1-4e7e-6f20a4a676e2@gmail.com> Date: Thu, 20 Jul 2023 10:22:30 +0100 In-Reply-To: (Richard Biener's message of "Thu, 20 Jul 2023 07:23:37 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-20.6 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Richard Biener writes: #> On Thu, 20 Jul 2023, Richard Sandiford wrote: > >> Jeff Law via Gcc-patches writes: >> > On 7/19/23 04:25, Richard Biener wrote: >> >> On Wed, 19 Jul 2023, YunQiang Su wrote: >> >> >> >>> Eric Botcazou ?2023?7?19??? 17:45??? >> >>>> >> >>>>> I don't see that. That's definitely not what GCC expects here, >> >>>>> the left-most word of the doubleword should be unchanged. >> >>>>> >> >>>>> Your testcase should be a dg-do-run and probably more like >> >>>>> >> >>>>> NOMIPS16 int __attribute__((noipa)) test (const unsigned char *buf) >> >>>>> { >> >>>>> int val; >> >>>>> ((unsigned char*)&val)[0] = *buf++; >> >>>>> ((unsigned char*)&val)[1] = *buf++; >> >>>>> ((unsigned char*)&val)[2] = *buf++; >> >>>>> ((unsigned char*)&val)[3] = *buf++; >> >>>>> return val; >> >>>>> } >> >>>>> int main() >> >>>>> { >> >>>>> int val = 0x01020304; >> >>>>> val = test (&val); >> >>>>> if (val != 0x01020304) >> >>>>> abort (); >> >>>>> } >> >>>>> >> >>>>> not sure if I got endianess correct. Now, the question is what >> >>>>> WORD_REGISTER_OPERATIONS implies for a bitfield insert and what >> >>>>> the MIPS ABI says for returning SImode. >> >>>> >> >>> >> >>> MIPS N64 ABI uses 2 GPR for integer return values. >> >>> If the return value is SImode, the first v0 register is used, and it >> >>> must be sign-extended, >> >>> aka the bits[64-31] are all same. >> >>> >> >>> Yes, it is same for signed and unsigned int32. >> >>> >> >>> https://irix7.com/techpubs/007-2816-004.pdf >> >>> Page 6: >> >>> 32-bit integer (int) parameters are always sign-extended when passed >> >>> in registers, >> >>> whether of signed or unsigned type. [This issue does not arise in the >> >>> o32-bit ABI.] >> >> >> >> Note I think Andrews comment#7 in the PR is spot-on then, the issue >> >> isn't the bitfield inserts but the compare where combine elides >> >> the sign_extend in favor of a subreg. That's likely some wrongdoing >> >> in simplify-rtx in the context of WORD_REGISTER_OPERATIONS. >> > And I think it raises a real question about the use of GPR (which maps >> > to SImode and DImode for 64bit MIPS targets) on the conditional >> > branching patterns in mips.md. >> > >> > So while this code works: >> > >> >> (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ]) >> >> (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]) 4))) "/app/example.cpp":7:29 -1 >> >> (nil)) >> >> Haven't had chance to compile and look at it properly, but this subreg >> seems suspicious for MIPS, given the definition of TRULY_NOOP_TRUNCATION. >> We should instead use a truncdisi2 to narrow reg:DI 200 to an SI register, >> and then sign_extend it. >> >> This is easily missed in target-independent code because so few targets >> define TRULY_NOOP_TRUNCATION. > > Can we easily get rid of it? Not easily. The problem is that the original 64-bit ISA says that the behaviour of a 32-bit arithmetic instruction is undefined if the inputs aren't in sign-extended form. (A bit like GCC CONST_INTs :)) So: // $2 = 0x0_8000_0000 addiu $3,$2,$2 has undefined behaviour, it must instead be: // $2 = 0xffff_ffff_8000_0000 The purpose of TRULY_NOOP_TRUNCATION is to ensure that we never form an SImode register by taking a lowpart subreg of a DImode (or wider) register. In other words, things are inverted to that truncating DI to SI is a sign-extend operation (represented in RTL as a trunc) while sign-extending from SI to DI is free (lowered to nothing after RA). Richard