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 482243858D37 for ; Mon, 22 May 2023 10:04:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 482243858D37 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 _____8Ax3eojPmtkxeMKAA--.18764S3; Mon, 22 May 2023 18:04:19 +0800 (CST) Received: from [10.20.4.171] (unknown [10.20.4.171]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxLb8hPmtkSOpuAA--.56430S3; Mon, 22 May 2023 18:04:18 +0800 (CST) Subject: Re: [PATCH v4 0/6] LoongArch linker relaxation support. To: Xi Ruoyao , binutils@sourceware.org Cc: xuchenghua@loongson.cn, chenglulu@loongson.cn, liuzhensong@loongson.cn, i.swmail@xen0n.name, maskray@google.com References: <20230522013441.3074776-1-mengqinggang@loongson.cn> <3d26b5ef4aa4ec462c3232a21527424b933dd70a.camel@xry111.site> From: mengqinggang Message-ID: Date: Mon, 22 May 2023 18:04:17 +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: <3d26b5ef4aa4ec462c3232a21527424b933dd70a.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8BxLb8hPmtkSOpuAA--.56430S3 X-CM-SenderInfo: 5phqw15lqjwttqj6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBjvJXoW7ZFWrKw1xAw13Wr1DKF1rWFg_yoW8KFWrpF W7Ar47t3WkGF1rJr4Iva1xXF4Fva95Ka13Zr4rXrWxC398X3WFqFsYya15AF9rKr1xGayj va1DtwnruF1Yv37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bxAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_JrI_Jryl8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AI xVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx1l5I8CrVACY4xI64 kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm 72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04 k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18 MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr4 1lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1l IxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4 A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07j8yCJUUUUU= X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,NICE_REPLY_A,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_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: For -fsection-anchors, I think it is less affected by relax.  Could you please give some special question about this? On LoongArch architecture, -mno-explicit-relocs may have a higher performance than -mexplicit-relocs for some large program. 在 2023/5/22 下午1:40, Xi Ruoyao 写道: > On Mon, 2023-05-22 at 09:34 +0800, mengqinggang wrote: >> This is the v4 version of patches to support loongarch linker relax. >> This version mainly rebase to the master branch. >> >> The binutils, gcc, glibc and Spec2006 testcases is ok. > Have you tried the kernel and GRUB? AFAIK they are the most "fragile" > package regarding to this kind of optimization. The RISC-V port of them > uses -mno-relax. > >> Now, only the instrunctions expand from macro (la.local, la.global, 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. > I guess -fsection-anchors (enabled by default with any optimization > level but -O0) can also affect. Maybe we should change GCC to use -mno- > explicit-relocs and maybe -fno-section-anchors for -Os then. For -O1/- > O2/-O3 the benefit of scheduling is more important on a modern CPU. > >> There are two code sequence can be relaxed in LoongArch. The first one >> is "pcala12i + addi.d", which can be relaxed to pcaddi. Another one is >> "pcalau12i + ld.d", which can be relaxed to "pcalau12i + addi.d". And it can be >> relaxed to pcaddi one more time. Pcaddi instrunction can address a signed 22 >> bits 4-byte alinged offset relative to pc. >> >> In the future, the TLS LE code sequence and function call in medium >> code mode would be relaxed too. >> >> For .align directive, some small problems cannot be perfectly solved (see >> http://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation). >> >> >> The new relocs document at here: >>   https://github.com/loongson/LoongArch-Documentation/pull/77 > But the repo is archived so any PR in it should be considered dead. May > I "hijack" the discussion to ask the rationale about archiving it? Note > that if you want to mean "it's stable and should not be changed w/o a > major update" you should create a tag and release instead of archiving > it. Archiving basically mean "the repo is dead or moved elsewhere". > >