From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 1651E3858C53 for ; Wed, 17 Jan 2024 09:58:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1651E3858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=loongson.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1651E3858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705485491; cv=none; b=VQPLJIryURPBMBuVH3F7W1ggpa/mF1vO0dIBtux+zBzoUsxbZhgNbiYNnwzsU1QMStROGsvc4ALDoGrsTBwqz4LiJfr1V03k39wsrWULe5zZXW3bk/XZDW5VIU0XSeHdLYCz2IGTudaf1vbCbl7fx7+AFBSCFVsgYuESjnRmt0A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705485491; c=relaxed/simple; bh=HJiABN4dLsFLJ4ZClfEo+8hj9WCWPARbFCWPCo5Cwu0=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=KNmeXa6FnvWJKjwDxlBiwy59kzeI8eSYbxgvpqPiTpnU0ex2kjEdtFBrp3DO1Dy8yNGU6KCz+wCuljm70g4rMY9pYULhlmGjfhU2RaFdBzQa+IVxgJcjf3eBuUkU/w19llampsvbenatMzRv1UZ8kQSp/a6jnCIRqt5wOfE165o= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail.loongson.cn ([114.242.206.163]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQ2gQ-0005Oo-2i for gcc-patches@gcc.gnu.org; Wed, 17 Jan 2024 04:58:08 -0500 Received: from loongson.cn (unknown [10.20.4.107]) by gateway (Coremail) with SMTP id _____8DxvuuopKdleCABAA--.5353S3; Wed, 17 Jan 2024 17:58:00 +0800 (CST) Received: from [10.20.4.107] (unknown [10.20.4.107]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Bx8OSnpKdlLUYGAA--.32532S3; Wed, 17 Jan 2024 17:57:59 +0800 (CST) Subject: Re: [PATCH v2 2/2] LoongArch: When the code model is extreme, the symbol address is obtained through macro instructions regardless of the value of -mexplicit-relocs. To: Xi Ruoyao , gcc-patches@gcc.gnu.org Cc: i@xen0n.name, xuchenghua@loongson.cn References: <20240105034021.30177-1-chenglulu@loongson.cn> <20240105034021.30177-3-chenglulu@loongson.cn> <0fe0f370-a593-d060-d260-0e190986f833@loongson.cn> <4cdfda6960e75ccc6ccea6263ac02e79c9dba572.camel@xry111.site> <74482b5cbfef5a9d07185cd63430b3907fb389d1.camel@xry111.site> <7808ffa81093a41202b1a5c3cf12b76482741b1e.camel@xry111.site> <16929185-d182-c1d9-ba81-c8ce9dbe7eaf@loongson.cn> From: chenglulu Message-ID: <4f2eb5a0-0791-0df8-d957-9fda9b122c85@loongson.cn> Date: Wed, 17 Jan 2024 17:57:59 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; 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:AQAAf8Bx8OSnpKdlLUYGAA--.32532S3 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBj93XoWxtw43GryxJw4UKrW3trWxZrc_yoWxZw1kpr 97tFy7JrW5Cr18Jr1Utr1UJryUtr1UJ3WUWr1UJFy8Jr4Dtr1jqr48Xr1jgF15Jr48Jr1U Xr1UJ347Zr1UJrXCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUU9ab4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07 AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwCFI7km07C2 67AKxVWUAVWUtwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI 8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWU CwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r 1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsG vfC2KfnxnUUI43ZEXa7IU8czVUUUUUU== Received-SPF: pass client-ip=114.242.206.163; envelope-from=chenglulu@loongson.cn; helo=mail.loongson.cn X-Spam_score_int: -36 X-Spam_score: -3.7 X-Spam_bar: --- X-Spam_report: (-3.7 / 5.0 requ) BAYES_00=-1.9,NICE_REPLY_A=-1.748,SPF_HELO_NONE=0.001,SPF_PASS=-0.001,T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,LIKELY_SPAM_BODY,NICE_REPLY_A,SPF_FAIL,SPF_HELO_PASS,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: 在 2024/1/17 下午5:50, Xi Ruoyao 写道: > On Wed, 2024-01-17 at 17:38 +0800, chenglulu wrote: >> 在 2024/1/13 下午9:05, Xi Ruoyao 写道: >>> 在 2024-01-13星期六的 15:01 +0800，chenglulu写道： >>>> 在 2024/1/12 下午7:42, Xi Ruoyao 写道: >>>>> 在 2024-01-12星期五的 09:46 +0800，chenglulu写道： >>>>> >>>>>>> I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS: >>>>>>> we need a target hook to tell the generic code >>>>>>> UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll >>>>>>> see millions lines of messages like >>>>>>> >>>>>>> ../../gcc/gcc/tree.h:4171:1: note: non-delegitimized UNSPEC >>>>>>> UNSPEC_LA_PCREL_64_PART1 (42) found in variable location >>>>>> I build GCC with -mcmodel=extreme in BOOT_CFLAGS, but I haven't reproduced the problem you mentioned. >>>>>> >>>>>>       $ ../configure --host=loongarch64-linux-gnu --target=loongarch64-linux-gnu --build=loongarch64-linux-gnu \ >>>>>>           --with-arch=loongarch64 --with-abi=lp64d --enable-tls --enable-languages=c,c++,fortran,lto --enable-plugin \ >>>>>>           --disable-multilib --disable-host-shared --enable-bootstrap --enable-checking=release >>>>>>       $ make BOOT_FLAGS="-mcmodel=extreme" >>>>>> >>>>>> What did I do wrong?:-( >>>>> BOOT_CFLAGS, not BOOT_FLAGS :). >>>>> >>>> This is so strange. My compilation here stopped due to syntax problems, >>>> >>>> and I still haven't reproduced the information you mentioned about >>>> UNSPEC_LA_PCREL_64_PART1. >>> I used: >>> >>> ../gcc/configure --with-system-zlib --disable-fixincludes \ >>>                   --enable-default-ssp --enable-default-pie \ >>>                   --disable-werror --disable-multilib \ >>>                   --prefix=/home/xry111/gcc-dev >>> >>> and then >>> >>> make STAGE1_{C,CXX}FLAGS="-O2 -g" -j8 \ >>>       BOOT_{C,CXX}FLAGS="-O2 -g -mcmodel=extreme" &| tee gcc-build.log >>> >>> I guess "-g" is needed to reproduce the issue as well as the messages >>> were produced in dwarf generation. >>> >> I have reproduced this problem, and it can be solved by adding a hook. >> >> But unfortunately, when using '-mcmodel=extreme -mexplicit-relocs=always' >> >> to test spec2006 403.gcc, an error will occur. Others have not been >> tested yet. >> >> I roughly debugged it, and the problem should be this: >> >> The problem is that the address of the instruction ‘ldx.d $r12, $r25, >> $r6’ is wrong. >> >> Wrong assembly: >> >>     5826         pcalau12i       $r13,%got_pc_hi20(recog_data) >>   5827         addi.d  $r12,$r0,%got_pc_lo12(recog_data) >>   5828         lu32i.d $r12,%got64_pc_lo20(recog_data) >>   5829         lu52i.d $r12,$r12,%got64_pc_hi12(recog_data) >>   5830         ldx.d   $r12,$r13,$r12 >>   5831         ld.b    $r8,$r12,997 >>   5832         .loc 1 829 18 discriminator 1 view .LVU1527 >>   5833         ble     $r8,$r0,.L476 >>   5834         ld.d    $r6,$r3,16 >>   5835         ld.d    $r9,$r3,88 >>   5836 .LBB189 = . >>   5837         .loc 1 839 24 view .LVU1528 >>   5838         alsl.d  $r7,$r19,$r19,2 >>   5839         ldx.d   $r12,$r25,$r6 >>   5840         addi.d  $r17,$r3,120 >>   5841 .LBE189 = . >>   5842         .loc 1 829 18 discriminator 1 view .LVU1529 >>   5843         or      $r13,$r0,$r0 >>   5844         addi.d  $r4,$r12,992 >> >> Assembly that works fine using macros: >> >> 3040         la.global       $r12,$r13,recog_data >> 3041         ld.b    $r9,$r12,997 >> 3042         ble     $r9,$r0,.L475 >> 3043         alsl.d  $r5,$r16,$r16,2 >> 3044         la.global       $r15,$r17,recog_data >> 3045         addi.d  $r4,$r12,992 >> 3046         addi.d  $r18,$r3,48 >> 3047         or      $r13,$r0,$r0 >> >> Comparing the assembly, we can see that lines 5844 and 3045 have the >> same function, >> >> but there is a problem with the base address register optimization at >> line 5844. >> >> regrename.c.283r.loop2_init: >> >> (insn 6 497 2741 34 (set (reg:DI 180 [ ivtmp.713D.15724 ]) >>          (const_int 0 [0])) "regrename.c":829:18 discrim 1 156 >> {*movdi_64bit} >> (nil)) >> (insn 2741 6 2744 34 (parallel [ >>              (set (reg:DI 1502) >>                  (unspec:DI [ >>                          (symbol_ref:DI ("recog_data") [flags 0xc0] >> ) >>                      ] UNSPEC_LA_PCREL_64_PART1)) >>              (set (reg/f:DI 1479) >>                  (unspec:DI [ >>                          (symbol_ref:DI ("recog_data") [flags 0xc0] >> ) >>                      ] UNSPEC_LA_PCREL_64_PART2)) >>          ]) -1 >>       (expr_list:REG_UNUSED (reg/f:DI 1479) >> (nil))) >> (insn 2744 2741 2745 34 (set (reg/f:DI 1503) >>          (mem:DI (plus:DI (reg/f:DI 1479) >>                  (reg:DI 1502)) [0  S8 A8])) 156 {*movdi_64bit} >>       (expr_list:REG_EQUAL (symbol_ref:DI ("recog_data") [flags 0xc0] >> ) >> (nil))) >> >> >> Virtual register 1479 will be used in insn 2744, but register 1479 was >> assigned the REG_UNUSED attribute in the previous instruction. >> >> The attached file is the wrong file. >> The compilation command is as follows: >> >> $ ./gcc/cc1 -fpreprocessed regrename.i -quiet -dp -dumpbase regrename.c >> -dumpbase-ext .c -mno-relax -mabi=lp64d -march=loongarch64 -mfpu=64 >> -msimd=lasx -mcmodel=extreme -mtune=loongarch64 -g3 -O2 >> -Wno-int-conversion -Wno-implicit-int -Wno-implicit-function-declaration >> -Wno-incompatible-pointer-types -version -o regrename.s >> -mexplicit-relocs=always -fdump-rtl-all-all > I've seen some "guality" test failures in GCC test suite as well. > Normally I just ignore the guality failures but this time they look very > suspicious. I'll investigate these issues... > I've also seen this type of failed regression tests and I'll continue to look at this issue as well.