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 52B1F385735E for ; Mon, 6 Mar 2023 08:13:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 52B1F385735E 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 _____8CxQMyKoAVkHrQIAA--.10720S3; Mon, 06 Mar 2023 16:12:58 +0800 (CST) Received: from [10.20.4.52] (unknown [10.20.4.52]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxC76KoAVkJj9MAA--.887S2; Mon, 06 Mar 2023 16:12:58 +0800 (CST) Subject: Re: [PATCH 0/2] LoongArch: testsuite: Fix tests related to stack To: Xi Ruoyao Cc: gcc-patches@gcc.gnu.org, WANG Xuerui , Chenghua Xu , Yujie Yang , Mike Stump References: <20230303084011.8989-1-xry111@xry111.site> <9b7181b2-00b5-9fd1-316e-979cf580e6e1@loongson.cn> <87e2942cfc448710c4759aedbbe0f34f05a76aeb.camel@xry111.site> <8a50784b10484b42a5b747338bc483a79c582917.camel@xry111.site> From: Lulu Cheng Message-ID: Date: Mon, 6 Mar 2023 16:12:57 +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: <8a50784b10484b42a5b747338bc483a79c582917.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8BxC76KoAVkJj9MAA--.887S2 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBjvJXoWxCFyrKw13CFWUtF13tr4fXwb_yoWrWw1rpr 48tFy7KFW8Wr18tF1Utr1UtFyrtr18Aa4DJryUKF10vr15Gryjqr1jqr4jgF17Xr48JrW2 vr17Gr42vr17G3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bxAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jrv_JF1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS 0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc02F40EFcxC0V AKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1l Ox8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l42 xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWU GwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI4 8JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4U MIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I 8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jUsqXUUUUU= X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,BODY_8BITS,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/3/6 下午4:02, Xi Ruoyao 写道: > On Mon, 2023-03-06 at 13:59 +0800, Xi Ruoyao via Gcc-patches wrote: >> On Mon, 2023-03-06 at 11:16 +0800, Xi Ruoyao wrote: >> >> /* snip */ >> >>>>> Sorry for the late reply, the first patch I think is fine. But I haven't >>>>> reproduced the problem of the second mail. >>>>> >>>>> Is there any special option in the configuration? >>>> Oh some strange thing might be happening... I'll try to figure out what >>>> has caused the behavior difference. >>> Oh no, the difference is caused by --enable-default-pie. >>> >>> Maybe I should just add -fno-PIE for the dg-options.  But now I'm still >>> puzzled: why would -fPIE affect code generation on LoongArch?  AFAIK all >>> the code we are generating is position independent (at least for now). >> Without -fPIE, the compiler stores a register with no reason: > Pushed the first patch as r13-6501. The second one is dropped and I've > created PR109035 for the "unnecessary store" issue (after some failed > attempts to triage it). Has the first patch been merged into the main branch yet? I think there is one more test case that needs to be modified: --- a/gcc/testsuite/gcc.target/loongarch/prolog-opt.c +++ b/gcc/testsuite/gcc.target/loongarch/prolog-opt.c @@ -1,7 +1,7 @@  /* Test that LoongArch backend stack drop operation optimized. */  /* { dg-do compile } */ -/* { dg-options "-O2 -mabi=lp64d" } */ +/* { dg-options "-O2 -mabi=lp64d -fno-stack-protector" } */  /* { dg-final { scan-assembler "addi.d\t\\\$r3,\\\$r3,-16" } } */ >> $ cat t.c >> int test(int x) >> { >>         char buf[128 << 10]; >>         return buf[x]; >> } >> $ ./gcc/cc1 t.c -nostdinc  -O2 -fdump-rtl-all -o- 2>/dev/null | grep test: -A20 >> test: >> .LFB0 = . >>         lu12i.w $r13,-135168>>12                        # 0xfffffffffffdf000 >>         ori     $r13,$r13,4080 >>         add.d   $r3,$r3,$r13 >> .LCFI0 = . >>         lu12i.w $r12,-131072>>12                        # 0xfffffffffffe0000 >>         lu12i.w $r13,131072>>12                 # 0x20000 >>         add.d   $r13,$r13,$r12 >>         addi.d  $r12,$r3,16 >>         add.d   $r12,$r13,$r12 >>         lu12i.w $r13,131072>>12                 # 0x20000 >>         st.d    $r12,$r3,8 >>         ori     $r13,$r13,16 >>         ldx.b   $r4,$r12,$r4 >>         add.d   $r3,$r3,$r13 >> .LCFI1 = . >>         jr      $r1 >> .LFE0: >>         .size   test, .-test >>         .section        .eh_frame,"aw",@progbits >> >> Note the "st.d  $r12,$r3,8" instruction is completely meaningless. >> >> The t.c.300r.ira dump contains some "interesting" thing: >> >> Pass 0 for finding pseudo/allocno costs >> >>     a0 (r87,l0) best GR_REGS, allocno GR_REGS >>     a1 (r84,l0) best NO_REGS, allocno NO_REGS >>     a2 (r83,l0) best GR_REGS, allocno GR_REGS >> >>   a0(r87,l0) costs: SIBCALL_REGS:2000,2000 JIRL_REGS:2000,2000 CSR_REGS:2000,2000 GR_REGS:2000,2000 FP_REGS:8000,8000 ALL_REGS:32000,32000 MEM:8000,8000 >>   a1(r84,l0) costs: SIBCALL_REGS:1000000,1000000 JIRL_REGS:1000000,1000000 CSR_REGS:1000000,1000000 GR_REGS:1000000,1000000 FP_REGS:1004000,1004000 ALL_REGS:1016000,1016000 MEM:1004000,1004000 >>   a2(r83,l0) costs: SIBCALL_REGS:1000000,1000000 JIRL_REGS:1000000,1000000 CSR_REGS:1000000,1000000 GR_REGS:1000000,1000000 FP_REGS:1004000,1004000 ALL_REGS:1008000,1008000 MEM:1004000,1004000 >> >> >> Here r84 is the pseudo register for ($frame - 131072).  Any idea why the >> compiler selects "NO_REGS" here? >> >> FWIW RISC-V port suffers the same issue: >> https://godbolt.org/z/aPorqj73b. >