<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Jul 17, 2017 at 11:14 AM, PkmX <span dir="ltr"><<a href="mailto:pkmx.tw@gmail.com" target="_blank">pkmx.tw@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently we are thinking about adding relaxation to lld as a two-pass<br>
algorithm:<br>
<br>
1. First we iterate over each relaxable section and present each relax<br>
relocation to Target, which can perform modification to the byte<br>
content. To support efficient deletion, each RelaxableSection contains<br>
an iovec-style array of (ptr, len) tuples to keep track each segment<br>
we want to keep, and we also need maps between original input address<br>
/ final address after relaxation to speed up calculation.<br>
2. Calculate updated address for each symbol / relocation taking<br>
deleted bytes into account.<br>
<br>
I think both of these steps can be paralleled on a per-section basis.<br>
We loop over these two steps until no more relaxation can be performed<br>
or the desired number of iterations is met, then in `writeTo` of each<br>
RelaxableSection we just write out each [ptr, ptr + len) range of<br>
bytes and perform relocations. This should ensure minimal copying of<br>
the section contents is done.<br>
<span><br>
On Wed, Jul 12, 2017 at 2:27 AM, Rui Ueyama via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
</span><span>> 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.<br>
><br>
<br>
</span>Yes. However given that LLVM currently only have very incomplete MC<br>
support for RISC-V, what would be the way to add tests to lld which<br>
seems depend on having a working `llvm-mc`? I suppose calling<br>
binutils's as is out of the question.</blockquote><div><br></div><div>Checking in a binary file is okay as an interim solution. We can replace them when llvm-mc is fixed.</div></div></div></div>