<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 11, 2016 at 7:31 PM, Andrew Kelley <span dir="ltr"><<a href="mailto:superjoe30@gmail.com" target="_blank">superjoe30@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thank you for this exciting update about LLD.<div><br></div><div>I will start experimenting with using liblld in Zig (<a href="http://ziglang.org/" target="_blank">http://ziglang.org/</a>) instead of starting a child process to invoke the system linker. Once liblld makes it into the various package managers out there, this will be a big step toward painless cross-platform compilation.</div><div><br></div><div>It should also reduce one of the compilation speed bottlenecks, since I could transition from writing objects to the file system to passing liblld LLVM modules directly. Is that correct?</div></div></blockquote><div><br></div><div>LLD's driver currently takes only a command line argument strings, so you need to write ELF files to a filesystem and read them back at the moment.</div><div><br></div><div>Theoretically, we could accept a list of command line strings and MemoryBuffer objects (instead of filenames) so that we can link in-memory ELF object files. Adding that feature shouldn't be hard.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra">-Andrew</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Sun, Dec 11, 2016 at 10:04 PM, Rui Ueyama via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div>Hi,</div><div><br></div><div>Now that 2016 is almost over, I wanted to look back and summarize the progress we've made to LLD this year, as I guess most people who are not looking closely at LLD don't know very well about the current status. I think I can say that this year was a fantastic year for LLD. Now I'm pretty sure that that is going to be a serious (and better, in my opinion) alternative to the existing GNU linkers thanks to all the improvements we've made this year.</div><div><br></div><div>LLD is now able to link most x86-64 userland programs. The FreeBSD project and we are trying to make LLD the system default linker of the operating system, and except a few tricky programs such as the kernel or a boot loader, the linker works mostly fine. We are still working on implementing long-tail features/bugs, but I'd say that's just a matter of time. LLD supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and MIPS32/64, though completeness varies.</div><div><br></div><div>Looks like there are already a few systems that are using LLD as system linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself has build options to use LLD to build them.</div><div><br></div><div>It is hard to argue about the complexity of a program quantitatively, and of course I'm biased, but I believe we succeeded to maintain LLD code base clean, easy to read, and easy to add new features. It is just 20k lines of modern C++ code which is much smaller than GNU linkers.</div><div><br></div><div>Even though LLD was fast from day one, LLD got faster this year, despite it got a lot of new features. Below is a chart of Clang link time for every commit made to the LLD repository this year. At the beginning of this year, LLD took about 16 seconds to produce a 1.5 GB clang (debug build) executable. Now, it takes about 14.5 seconds on single core and 8.5 seconds on 20 cores (*1). ld.gold takes about 25 seconds and 20 seconds, respectively, so we've widen the gap. You can see the benchmark results here (*2). If you have a problem of too long link time, I'd recommend to try LLD.</div><div><br></div><div>Last but not least, a lot of people joined to the LLD development this year to make LLD better. We are growing as a community, and I'm very happy about that!</div><div><br></div><div>Thanks,</div><div>Rui<br></div><div><br></div><img src="https://mail.google.com/mail/u/0/?ui=2&ik=5496f259ef&view=att&th=158f0939ee1da14c&attid=0.3&disp=safe&realattid=ii_iwldsqlj2_158f0939ee1da14c&zw" style="margin-right: 25px;"><div>(*1) My machine has Ivy Bridge Xeon 2.8 GHz 20 physical cores (40 hyper-threading cores). To measure a single-thread performance, I pinned a process to (physical and hyper-threading) core 0. To measure a multi-thread performance, I pinned to CPU socket 2, so that a process gets 10 physical cores (20 hyperthreading cores).<br></div><div><br></div><div>(*2) <a href="https://docs.google.com/spreadsheets/d/1VvOqiU5JvqlxU7aof8gsbh-yweeNchMgtkamyXrwzrA/edit?usp=sharing" target="_blank">https://docs.google.com/s<wbr>preadsheets/d/1VvOqiU5JvqlxU7a<wbr>of8gsbh-yweeNchMgtkamyXrwzrA/<wbr>edit?usp=sharing</a>. Changes with more than 1% rise or drop compared to the average of previous 5 commits are colored in green or red, respectively.</div></div>
<br></div></div>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>