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 234773858430 for ; Thu, 25 Jan 2024 00:49:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 234773858430 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 234773858430 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=1706143744; cv=none; b=hM10AYSm6CILHejkYZcTj7371pG9IkJEUWPqHnR4PwHaGyFwCSBRYvFM8nIiNNDeifQTBSr326u2PP71PRtYtYHkRpg/F+dQvRyg5GZQ6d42f3hYND9wLFd7oKxBmjlpQ5fj6zKZ5OeI5u350sMezLg5+ioO0Ea2Mz0GORlXEbc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706143744; c=relaxed/simple; bh=usrXfj6iyob6aqRBOqM97qv3Qlr9y2935jD7b7ElOGw=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=qmrBdXPn2peH9fzuIhZA7f24hkwkLQxYWXuUzo6dTcVR5QO0iJr7N1Bf3GSdxiqGYmdU0bHld8Rm1DPwUkRNXqRlpna30IZRE10P6qT6f30/IGSwY5Xxt3YjTxgiiwNSKYeVif60AED5ziFNVkuJor3k7xSR73uaZMxxGXMByvQ= 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 1rSnvO-0002ar-Vv for gcc-patches@gcc.gnu.org; Wed, 24 Jan 2024 19:49:01 -0500 Received: from loongson.cn (unknown [10.20.4.107]) by gateway (Coremail) with SMTP id _____8DxbOnvr7FlriMFAA--.9802S3; Thu, 25 Jan 2024 08:48:48 +0800 (CST) Received: from [10.20.4.107] (unknown [10.20.4.107]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxVMztr7Flrw0YAA--.44965S3; Thu, 25 Jan 2024 08:48:46 +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> <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> <883986d4-e17b-6381-b3ec-75519859e7ea@loongson.cn> <645b17748995b75fc2a9c4368f8ab5d89cc0ff10.camel@xry111.site> From: chenglulu Message-ID: <182d66ec-01b7-9af0-2e96-a863ecc0db95@loongson.cn> Date: Thu, 25 Jan 2024 08:48:45 +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: <645b17748995b75fc2a9c4368f8ab5d89cc0ff10.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8BxVMztr7Flrw0YAA--.44965S3 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBj93XoW7Cry5Jr4rKF4xtryxury3Awc_yoW8uw17pF Z7Ga15JFZ8tr48G34IyFWIgryjvr4xtF4UWry5Jryjyw4DtF12gayIkrWq9a4UZws5KF4a vry3t343uF4DAagCm3ZEXasCq-sJn29KB7ZKAUJUUUU5529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUv0b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ Gr0_Gr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx1l5I 8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1Y6r17McIj6I8E87Iv67AK xVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzV AYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E 14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r 4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1QVy3UU UUU== Received-SPF: pass client-ip=114.242.206.163; envelope-from=chenglulu@loongson.cn; helo=mail.loongson.cn X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9,NICE_REPLY_A=-0.817,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.8 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,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/24 上午3:36, Xi Ruoyao 写道: > On Mon, 2024-01-22 at 15:27 +0800, chenglulu wrote: >>>> 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. > Try removing the TARGET_DELEGITIMIZE_ADDRESS hook? After eating some > unhealthy food in the midnight I realized the hook only > papers over the same issue caused spec2006 failure. I tried a bootstrap > with BOOT_CFLAGS=-O2 -g -mcmodel=extreme and TARGET_DELEGITIMIZE_ADDRESS > commented out, and there is no more spurious "note: non-delegitimized > UNSPEC UNSPEC_LA_PCREL_64_PART1 (42) found in variable location" things. > I feel that this hook is still written in a buggy way, so maybe removing > it will solve the spec2017 issue. > I found the problem. Binutils did not consider the four instructions when converting the type from TLS IE to TLS LE, which caused the conversion error.