bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/27433] New: RISC-V linker might lose relax opportunities since "


From: nelsonc1225 at sourceware dot org
Subject: [Bug ld/27433] New: RISC-V linker might lose relax opportunities since "again" doesn't work as expected
Date: Thu, 18 Feb 2021 08:59:40 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=27433

            Bug ID: 27433
           Summary: RISC-V linker might lose relax opportunities since
                    "again" doesn't work as expected
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: nelsonc1225 at sourceware dot org
  Target Milestone: ---

We find that the more relax passes, the more chances of relaxations are
reduced.  Originally, we set the boolean "again" to TRUE once the code is
actually deleted, and then we run the relaxations repeatedly if `again` is
still TRUE.  But "again" only works for the relax pass itself, and won't affect
others.  That is - we can not use "again" to re-run the entire relax passes
when we already enter into the following passes (cannot run the relax passes
backwards).

This is a minor enhancement, just that the commit
abd20cb637008da9d32018b4b03973e119388a0a will make the code size slightly 
 worse since the more relax passes.


Consider the following assembly case,

$ cat relax.s
.text
.global _start
_start:
    lla     a0, data_g
    .rept 0x3fffe
        nop
    .endr
    call _start
    .option rvc
    .align 2
    add     a0, a1, a2

    .data
    .global data_g
    .dword 0x0
data_g:
    .word 0x1000

$ riscv64-unknown-elf-as relax.s -o relax.o
$ riscv64-unknown-elf-ld --relax relax.o -o relax
$ riscv64-unknown-elf-objdump -d relax | grep -A 3 "auipc"
  1100ac:       fff00097                auipc   ra,0xfff00
  1100b0:       004080e7                jalr    4(ra) # 100b0 <_start>
  1100b4:       00c58533                add     a0,a1,a2
        ...

The "auipc + jalr" pattern is "call _start", and it should be relaxed to "jal"
since the range is at the boundary and enough.

Please see the details as follows,
https://sourceware.org/pipermail/binutils/2020-November/114223.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]