[llvm-dev] [LLD] Linker Relaxation
Rui Ueyama via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 13 16:54:38 PDT 2017
On Wed, Jul 12, 2017 at 7:57 PM, PkmX via llvm-dev <llvm-dev at lists.llvm.org>
> On Jul 13, 2017 02:07, "Rafael Avila de Espindola" <
> rafael.espindola at gmail.com> wrote:
> PkmX via llvm-dev <llvm-dev at lists.llvm.org> writes:
> > Note that RISC-V also handles alignment as part of relaxation, so it
> > isn't really optional. For example:
> > _start:
> > mv a0, a0
> > .p2align 2
> > li a0, 0
> > The assembler inserts a 3-byte padding (note: this behavior isn't
> > merged yet, see: https://github.com/riscv/riscv-binutils-gdb/pull/88):
> Why 3 bytes? The assembler knows the section alignment.
> I can see why another relaxation would require alignments to be
> revisited, but it should be possible to link without any relaxations,
> I agree the 3-byte padding is kinda strange. RISC-V insns are always
> multiples of 2 bytes and must be 2-byte aligned, so a 2-byte padding should
> suffice for the linker to re-align after relaxation. Indeed, the assembler
> should be able to configured to not emit any relaxation info and directly
> emit the correct number of nop's (w/o R_RISCV_ALIGN), and the object file
> can be linked without relaxation, but I don't think GAS can do that right
> now. (There is `.option norelax`, but currently it just emits zeros in the
> So the issue remains that GAS assumes linkers will always handle alignment
> (this is true for GNU ld even if --no-relax is given), so even for a basic
> RISC-V port lld needs to be extended to support relaxation.
I really wish you or someone else make a change to gas so that the
assembler doesn't emit code that depends on code shrinking relaxation.
Mandating code shrinking relaxation is I believe really bad from the
perspective of linker portability and also from the link speed point of
If gas requires it even with --no-relax, it sounds like it is just a bug
that needs fixing.
On Thu, Jul 13, 2017 at 6:07 AM, Bruce Hoult <bruce at hoult.org> wrote:
> > As a concrete suggestion, here is code for deciding how many bytes of
> > padding to emit.
> > For the case of .align 2 (4 byte alignment), it will emit a minimum of 3
> > a maximum of 6 bytes of padding. For .align 4 it emit a minimum of 15
> and a
> > maximum of 30 bytes of padding.
> Why does .align 2 need 3 to 6 bytes of padding though? I think for
> `.p2align n` only 2^n - 2 (or 2^n - 4 without RVC) padding bytes would be
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev