From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 4E08A3858C5E for ; Tue, 4 Apr 2023 09:15:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E08A3858C5E 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 _____8BxYU+l6itkeF8WAA--.34638S3; Tue, 04 Apr 2023 17:15:17 +0800 (CST) Received: from [10.20.4.52] (unknown [10.20.4.52]) by localhost.localdomain (Coremail) with SMTP id AQAAf8DxSL2k6itk4RwVAA--.17361S2; Tue, 04 Apr 2023 17:15:17 +0800 (CST) Subject: Re: [GCC14 PATCH] LoongArch: Optimize additions with immediates To: Xi Ruoyao , gcc-patches@gcc.gnu.org Cc: WANG Xuerui , Chenghua Xu References: <20230402140044.23073-1-xry111@xry111.site> <39b42972-9a0f-3ada-b9b9-2c53da946217@loongson.cn> <62922ce154f7f52147341b905d3c844cd50e6682.camel@xry111.site> From: Lulu Cheng Message-ID: <4b87d686-9add-5355-d778-eaf87c86df0c@loongson.cn> Date: Tue, 4 Apr 2023 17:15:16 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8DxSL2k6itk4RwVAA--.17361S2 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBjvJXoW7tw1UWFy8AFW5CrW3WF4Uurg_yoW8GFW3pr WxtFn0kFZ7Kryqyr1Ivw1rWF4Syr47Aa45XF1aqryUuws7ZFy3WrW3Wr909F4fJr9Y93Wj yFWxJa43X3WDAaDanT9S1TB71UUUUUDqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bI8YFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jrv_JF1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2 IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_JF0_Jw1lYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx AIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_ Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwI xGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcV C2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU2nYFDUUUU X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,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: 在 2023/4/4 下午4:40, Xi Ruoyao 写道: > On Tue, 2023-04-04 at 16:00 +0800, Xi Ruoyao via Gcc-patches wrote: >> On Tue, 2023-04-04 at 11:01 +0800, Lulu Cheng wrote: >> >> /* snip */ >> >>>> +unsigned long f10 (unsigned long x) { return x - 0x80000000l * 2; } >>>> +unsigned long f11 (unsigned long x) { return x - 0x80000000l * 2; } >>>  These two test cases are duplicates. >> /* snip */ >> >>>> +unsigned int g10 (unsigned int x) { return x - 0x80000000l * 2; } >>>> +unsigned int g11 (unsigned int x) { return x - 0x80000000l * 2; } >>> Ditto. >> I'll fix them in V2. >> >>> I found that adding this log test case gcc.target/loongarch/stack-check-cfa-1.c and gcc.target/loongarch/stack-check-cfa-2.c test failed. >>> Although the test fails, the generated assembly code is better, and there is no problem with the logic of the assembly code. I haven't checked the reason for this yet. >> Looks like the change hides PR109035 (like -fpie) for some reason. (But >> I still don't understand the root cause of PR109035 anyway.) > V2 sent with test cases fixed. > > /* snip */ > >> Technically there should be "addu16i.d $r3,$r3,-1" in the prologue and >> "addu16i.d $r3,$r3,2" in the epilogue, so we can avoid using r14/r13. >> I'll try modifying loongarch_expand_{pro,epi}logue for this. > Will do this later because I'm too stupid to understand > loongarch_first_stack_step function quickly :). > Thank you very much!