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

[mengqinggang <mengqinggang@loongson.cn>]

For -mexplicit-relocs, two addi.d may share one pcalau12i after gcc
scheduling like this:

     pcalau12i $t0, %pc_hi20(a)
     beq $t1, $t2, L1
     addi.d $t0, %pc_lo12(a)
L1:
     addi.d $t0, %pc_lo12(a)

If the first pcalau12i and addi.d be relaxed to pcaddi, the last
addi.d would get error address.


I guess riscv function call relaxation has the same question.
Riscv function call using 'call' instruction in  -mexplicit-relocs and
-mno-explicit-relocs. And R_RISCV_CALL relocation size is 8
bytes, so it can directly process two instructions expand from
'call' instruction.


在 2023/5/22 下午7:04, Xi Ruoyao 写道:
> On Mon, 2023-05-22 at 18:04 +0800, mengqinggang wrote:
>> For -fsection-anchors, I think it is less affected by relax.  Could
>> you
>> please
>> give some special question about this?
> Alright, it seems I'd misunderstood -fsection-anchors with -mno-
> explicit-relocs.  It generates things like:
>
> la.pcrel t0, .ANCHOR0 + 8
> la.pcrel t1, .ANCHOR0 + 16
>
> Not
>
> la.pcrel t2, .ANCHOR0
> addi.d t0, t2, 8
> addi.d t1, t2, 16
>
> which may puzzle the relaxation pass.
>
>> On LoongArch architecture, -mno-explicit-relocs may have a higher
>> performance
>> than -mexplicit-relocs for some large program.
> I'd consider this situation "bad" as a distro maintainer will need to
> decide this on per-package or even per-link-unit basis if (s)he really
> wants to squeeze the last drop of the performance...  Is there any
> possibility to make both scheduling and relaxation work?
>
>