From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 6CAF83858D3C for ; Mon, 22 Jan 2024 07:27:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6CAF83858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6CAF83858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705908451; cv=none; b=EYfr3TaCji/utWpSlTDpnxJcb0tHjJXZ+LLp8OF2wTiy1EXUj4XNF96X62EUT8uVB4SXVUoKzrbpl/GKQTd6WqJ9JT57gn5ElVWP7ZCUN/9CWAY0j/V3LuRx1h6FU7Y5pSF5rkDeXYKHTc7fu2Vf/ZFmecBZMJpbBKxsgWeoF0Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705908451; c=relaxed/simple; bh=BWa+KeypSv6Dkgyb0nauIk/SNoEY78LT+tguaCCnt4k=; h=Subject:From:To:Message-ID:Date:MIME-Version; b=wkhfpxX+igayOCEZBZLpaypdKDcto6HHpPcTE6uqD+i83gegUzSf+4mnYGwJB+WzJwXV1BUmt9Y3YGUIaO/ce1UGNQfP+11dvcRWpoYoInALGu/yznGItYKR0nj4Z5MDbXVzwORj5bf9Do5XhdQRanh/tErfehTpt48NdQwGlM0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from loongson.cn (unknown [10.20.4.107]) by gateway (Coremail) with SMTP id _____8DxWPDUGK5lRGYDAA--.13975S3; Mon, 22 Jan 2024 15:27:16 +0800 (CST) Received: from [10.20.4.107] (unknown [10.20.4.107]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxZMzTGK5lQggRAA--.19325S3; Mon, 22 Jan 2024 15:27:15 +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. From: chenglulu 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> <4f2eb5a0-0791-0df8-d957-9fda9b122c85@loongson.cn> <1d4d46647c3fff7d3fb6441d039048f52cf88886.camel@xry111.site> <6078d647-4176-8aec-3384-d87c34464266@loongson.cn> Message-ID: <883986d4-e17b-6381-b3ec-75519859e7ea@loongson.cn> Date: Mon, 22 Jan 2024 15:27:15 +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: <6078d647-4176-8aec-3384-d87c34464266@loongson.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8CxZMzTGK5lQggRAA--.19325S3 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBj93XoWxZr4kWw4kGw1DXFy7Gr4Dtrc_yoW5GFW5pa yDGay5KFW7A3WkGw1xtFWxXF1jyrW2ya1UXry5Jry0krn09rnrta9akr4Y9a4DXw4rWw4S va15t347uF4DAFXCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUv2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07 AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw 1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8j- e5UUUUU== X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,NICE_REPLY_A,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: 在 2024/1/19 下午4:51, chenglulu 写道: > > 在 2024/1/19 下午1:46, Xi Ruoyao 写道: >> On Wed, 2024-01-17 at 17:57 +0800, chenglulu wrote: >>>>> 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. >> The guality regression is simple: I didn't call >> delegitimize_mem_from_attrs (the default TARGET_DELEGITIMIZE_ADDRESS) in >> the custom implementation. >> >> The failure of this test case was because the compiler believes that two >> (UNSPEC_PCREL_64_PART2 [(symbol)]) instances would always produce the >> same result, but this isn't true because the result depends on PC.  Thus >> (pc) needed to be included in the RTX, like: >> >>    [(set (match_operand:DI 0 "register_operand" "=r") >>      (unspec:DI [(match_operand:DI 2 "") (pc)] >> UNSPEC_LA_PCREL_64_PART1)) >>     (set (match_operand:DI 1 "register_operand" "=r") >>      (unspec:DI [(match_dup 2) (pc)] UNSPEC_LA_PCREL_64_PART2))] >> >> With this the buggy REG_UNUSED notes were gone.  But it then prevented >> the CSE when loading the address of __tls_get_addr (i.e. if we address >> 10 TLE_LD symbols in a function it would emit 10 instances of "la.global >> __tls_get_addr") so I added an REG_EQUAL note for it.  For symbols other >> than __tls_get_addr such notes are added automatically by optimization >> passes. >> >> Updated patch attached. >> > I'm eliminating redundant la.global directives in my macro > implementation. > > I will be testing this patch. > > > > With this patch, spec2006 can pass the test, but spec2017 621 and 654 tests fail. I haven't debugged the specific cause of the problem yet.