[llvm-dev] [LLD] Linker Relaxation

[Rui Ueyama via llvm-dev]

I think the first thing we should do is to fix gas so that the assembler
doesn't require code shrinking optimization when relaxation is disabled.
That is more important than adding a RISC-V support to lld.

On Mon, Jul 17, 2017 at 11:14 AM, PkmX <pkmx.tw at gmail.com> wrote:

> Currently we are thinking about adding relaxation to lld as a two-pass
> algorithm:
>
> 1. First we iterate over each relaxable section and present each relax
> relocation to Target, which can perform modification to the byte
> content. To support efficient deletion, each RelaxableSection contains
> an iovec-style array of (ptr, len) tuples to keep track each segment
> we want to keep, and we also need maps between original input address
> / final address after relaxation to speed up calculation.
> 2. Calculate updated address for each symbol / relocation taking
> deleted bytes into account.
>
> I think both of these steps can be paralleled on a per-section basis.
> We loop over these two steps until no more relaxation can be performed
> or the desired number of iterations is met, then in `writeTo` of each
> RelaxableSection we just write out each [ptr, ptr + len) range of
> bytes and perform relocations. This should ensure minimal copying of
> the section contents is done.
>
> On Wed, Jul 12, 2017 at 2:27 AM, Rui Ueyama via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > By the way, since this is an optional code relaxation, we can think
> about it later. The first thing I would do is to add RISC-V support to lld
> without code shrinking relaxations, which I believe is doable by at most a
> few hundreds lines of code.
> >
>
> Yes. However given that LLVM currently only have very incomplete MC
> support for RISC-V, what would be the way to add tests to lld which
> seems depend on having a working `llvm-mc`? I suppose calling
> binutils's as is out of the question.


Checking in a binary file is okay as an interim solution. We can replace
them when llvm-mc is fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170717/65e76175/attachment.html>