From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 21E613858413 for ; Wed, 19 Jul 2023 12:22:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 21E613858413 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-pl1-x62e.google.com with SMTP id d9443c01a7336-1b8a462e0b0so42276865ad.3 for ; Wed, 19 Jul 2023 05:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689769355; x=1692361355; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KkgxT/8/GF/el+py5bDP3F4jkCdQYCz6CETpKzp98t8=; b=AVYGTYpLrCsTNucqdp4ZC993XqFIDTVs6eCGfnxKY5TEaZMYUzZNqtZfZmvpwuTBrn WhYmAMreOk8ZAB1/ZvGETZ03oWzRHMVzMSelPr6OElCXMFUTpDwJtYURjjp5Ri3FSZVP U19VUPpyakCARiXZ3QKJ/RHNLrwj3LCs/PYLmx+Q4HuFYk9BpCUdS9QA2/U2kgVMqVvy PS2gX+aZaZaexM0n4Ak3OMUzdGPdD/VnKFyKMLVbplsu503p5YGQrs7ANZKap3IRIr4+ 3Kt9La6NQlySD2LuESO9NzXK6PJubKsLCtjcre78CZZ0xtxH9C81oFRr4P84u/wfM3Hg VBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689769355; x=1692361355; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KkgxT/8/GF/el+py5bDP3F4jkCdQYCz6CETpKzp98t8=; b=Gq1v5dxh3TXxyqg6p6vbFQ3rTtzwvQIseBwJ5KQ2YeqdMXsbQtrCE7q0RRHIrylTfn 0li6Iah91yE9pRPjpQlL4OX6VWDpI5K/UBMy4JXGxIA07FoAGqJNYhhFQUGne2WV07QZ mN+AmeaaO7Wt1OW01sVrKq/+AhS4OcVOLrrnWIps2Idzbhhlbaj8+dxgtgMcwHHiJtp6 pRBekvZqv/u+Y2mz1y649uSvrcgkIaKmDlSkx+bHCr1mXnOeBUiftVhppUCkSQbadYTA jsW4DVRMA+VrQgt/8BYkBNUp023nEqmBdutxmD5oFM27CvjrcVB9p+FEStkKkA4phOz2 kc6w== X-Gm-Message-State: ABy/qLYs+CTg3MgBawnddxtPc/GlVhAnOpAeW7QjuKofHxttk11BjESc TLubpa0AEaU0zGvg1P4S5G8= X-Google-Smtp-Source: APBJJlHNMJLwUENDmM3C4yhziUbZrr4MM/4Y60AXGbJ46qe2TBY/hcEwKLpD+gfEYSb35/qob6PfNQ== X-Received: by 2002:a17:902:e749:b0:1b0:307c:e6fe with SMTP id p9-20020a170902e74900b001b0307ce6femr2923483plf.10.1689769354481; Wed, 19 Jul 2023 05:22:34 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id m8-20020a170902db0800b001b8b0ac2258sm3826629plx.174.2023.07.19.05.22.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jul 2023 05:22:34 -0700 (PDT) Message-ID: <3ad89c88-0cec-c2a1-4e7e-6f20a4a676e2@gmail.com> Date: Wed, 19 Jul 2023 06:22:32 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2] Store_bit_field_1: Use SUBREG instead of REG if possible Content-Language: en-US To: Richard Biener , YunQiang Su Cc: Eric Botcazou , gcc-patches@gcc.gnu.org, YunQiang Su , pinskia@gmail.com, ian@airs.com References: <20230719041639.2967597-1-yunqiang.su@cipunited.com> <2289802.ElGaqSPkdT@arcturus> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: 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)) > (jump_insn 23 20 24 2 (set (pc) > (if_then_else (le (subreg/s/u:SI (reg/v:DI 200 [ val+-4 ]) 4) > (const_int 0 [0])) > (label_ref 32) > (pc))) "/app/example.cpp":8:5 -1 > (int_list:REG_BR_PROB 440234148 (nil)) > -> 32) Normally the narrowing SUBREG in insn 23 would indicate we don't care about the bits outside SImode. But on a W_R_O targets we very much care because the hardware is going to ultimately do the comparison in 64 bits. As Andrew/Richi have indicated this very much points to combine as incorrectly eliminating the explict sign extension. Most likely because something saw the SUBREG and concluded those upper bits set by insn 20 were "don't care" bits. But it may ultimately be be better for the MIPS port to not expose a SImode comparison. Thus reducing the reliance on W_R_O and its under-specified semantics and ultimately having the RTL map more closely to what the hardware actually does/supports. That's the model we're working towards on the RISC-V port as well. I wouldn't be surprised if we eventually get to the point where we eliminate WORD_REGISTER_OPERATIONS entirely. And yes, bitfield operations are one of the nasty sticking points. The thinking for them is that we want to support bit manipulations where the bit position is variable. To do that we will emit an explicit sign extension after such operations. Then rely on improved REE to identify and remove those redundant extensions. Jeff Jeff