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 E44AD38AA25A for ; Tue, 6 Dec 2022 01:58:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E44AD38AA25A 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.171]) by gateway (Coremail) with SMTP id _____8Dxuuq9oY5jOXEDAA--.8296S3; Tue, 06 Dec 2022 09:58:21 +0800 (CST) Received: from [10.20.4.171] (unknown [10.20.4.171]) by localhost.localdomain (Coremail) with SMTP id AQAAf8DxbuC8oY5j408mAA--.28690S3; Tue, 06 Dec 2022 09:58:20 +0800 (CST) Subject: Re: [PATCH v1 0/6] LoongArch linker relaxation support. To: Xi Ruoyao , binutils@sourceware.org Cc: xuchenghua@loongson.cn, liuzhensong@loongson.cn, chenglulu@loongson.cn, i.swmail@xen0n.name, maskray@google.com References: <20221205080453.1352069-1-mengqinggang@loongson.cn> <31f6c836d79a8569d95a36c6b6fcfafddbdf459e.camel@xry111.site> From: mengqinggang Message-ID: <4643a2ed-cd3b-3948-73cf-c22a6b56b3d3@loongson.cn> Date: Tue, 6 Dec 2022 09:58:20 +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: <31f6c836d79a8569d95a36c6b6fcfafddbdf459e.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8DxbuC8oY5j408mAA--.28690S3 X-CM-SenderInfo: 5phqw15lqjwttqj6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBjvJXoW7uryDtr1kXFW7ArW5ZrW7twb_yoW8Cryfpr yfWwsrCF4kWFs3Wr18Kr4rG3WSvw4fGrW5Jay8t348Zw4DZFy0grZYyr4ktFZFvr1ava47 XF4rta4kZFn8ArDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bI8YFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jrv_JF1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2 IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx AIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_ Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwI xGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcV C2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU70PfDUUUU X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,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: We tried this method. We use R_LARCH_RELAX addend to distinguish two load sequences. But there is a problem that has not been solved. If there are two load sequences after a branch instruction like this:   branch ------------     | |   pcalau12i pcalau12i   ld.d ld.d After scheduling, two pcalau12i may be reduced to one and put before branch instruction like this: pcalau12i   branch -----------     | |    ld.d ld.d For this case, if one branch make a relax, another branch will get a mistake. But we will try to solve this question in relax v2 version. 在 2022/12/5 下午4:43, Xi Ruoyao 写道: > On Mon, 2022-12-05 at 16:04 +0800, mengqinggang wrote: >> Now, only the instrunctions expand from macro (la.local, la.got, etc.) at >> assembly time can be relaxed, because gcc instruction scheduling causes relax >> unable to handle some special cases. Gcc can add -mno-explicit-relocs option >> to generate macro instrunction. > Frankly, I don't like this. Can the compiler explicitly emit some > relocations to mark a instruction chain suitable for relaxation? Some > random thought: > > .reloc R_LARCH_RELOC_X 1 > pcalau12i $a0, %got_pc_hi20(sym_a) > .reloc R_LARCH_RELOC_X 2 > pcalau12i $a1, %got_pc_hi20(sym_b) > .reloc R_LARCH_RELOC_X 1 > ld.d $a0, $a0, %got_pc_lo12(sym_a) > .reloc R_LARCH_RELOC_X 2 > ld.d $a1, $a1, %got_pc_lo12(sym_b) > .reloc R_LARCH_RELOC_X 1 > ld.d $a0, $a0, 0 > .reloc R_LARCH_RELOC_X 2 > ld.d $a1, $a1, 0 > > Here "R_LARCH_RELOC_X" is an imaginary relocation type. We may be able > to use the different values of the 32-bit addend to distinguish two load > sequences interleaved after scheduling (I don't think there will be more > than 2147483647 load sequences in an object file). > > This is just some random thoughts, I don't understand the linking > process very well anyway. >