Re: [PATCH v4 0/6] LoongArch linker relaxation support.

[mengqinggang <mengqinggang@loongson.cn>]

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".
>
>