Greetings All, I was wondering what projects seem to improve the most from lld as a linker. It s seems to mostly be browsers and games but if someone has something else I would be interested to hear what. The site doesn't really talk about what projects improve the most so I would be curious to hear what does and even if possible why. Nick
As a quick summary, when we moved from gold to lld at Google we found that nearly every link sped up by a significant amount and took less memory. The only area that was a concern is gdb_index creation used more memory and slowed down the link, but it was still faster than gold. The range of binaries that sped up was everything from simple unit tests to large binaries. -eric On Fri, Aug 23, 2019 at 4:47 PM Nicholas Krause via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Greetings All, > > I was wondering what projects seem to improve the most from lld as a > linker. It s > > seems to mostly be browsers and games but if someone has something else > > I would be interested to hear what. The site doesn't really talk about what > > projects improve the most so I would be curious to hear what does and > > even if possible why. > > > Nick > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On Fri, Aug 23, 2019 at 07:47:10PM -0400, Nicholas Krause via llvm-dev wrote:> Greetings All, > > I was wondering what projects seem to improve the most from lld as a linker. > It s > > seems to mostly be browsers and games but if someone has something else > > I would be interested to hear what. The site doesn't really talk about what > > projects improve the most so I would be curious to hear what does and > > even if possible why.If I may take a moment to shamelessly plug the open source project in my signature, HardenedBSD. HardenedBSD is an open source downstream derivative of FreeBSD. Our primary goal is a clean-room re-implementation of the grsecurity patchset, based solely on publicly-available documentation. We love and adore PaX RAP. However, its having been covered by one or more patents and (moreso) its requiring a GPLv3 toolchain is a non-starter for an OS hoping to assist the efforts of certain members of the FreeBSD project in migrating to a permissively-licensed compiler toolchain. HardenedBSD's future currently lies with the llvm compiler toolchain. We already make use of non-Cross-DSO CFI and non-Cross-DSO SafeStack. We are the first enterprise OS to ship with a base operating system (and select third-party applications offered as binary packages or as build-it-yourself collection of ports) userland applied with non-Cross-DSO CFI and non-Cross-DSO SafeStack from the llvm toolchain. Our next milestone will be Cross-DSO CFI. Tasking exists that are shared among work porting both Cross-DSO CFI and Cross-DSO SafeStack (for example, deep integration of the sanitizer framework into the RTLD and into libc). Having a basic userland tightly integrated, moving in lockstep, with the kernel makes working on compiler toolchain-based features all the more interesting: you get to see your work applied to an entire corpus at once. No need to hack things together: it's all integrated in a developer-friendly fashion. HardenedBSD's future is currently tied to the continued success of the llvm compiler toolchain. And I'm okay with that. :) Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera at is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190823/75731623/attachment.sig>
As Eric mentioned, lld is generally much faster than GNU linkers, so many companies, especially ones that build large-scale programs (including Google) have migrated to lld and saw a significant reduction in build time, which improved developer productivity. So I'd say that large-scale program development seem to improve the most from lld. Other interesting area that seem to be benefited from lld is a bootloader and other UEFI programs. UEFI programs are in COFF file format (which is the same as Windows), and it was not easy to build a UEFI program in a host-independent way. There was a hacky way to workaround: for example, you can first build a UEFI program as an ELF program and transplant its text and data segments to an empty COFF file using objcopy. Or, maybe you can just use a Windows machine to link an UEFI program. lld solved the issue because lld is a cross-linker. You can create COFF object files using clang-cl and link the object files using lld/COFF to produce a UEFI program in a very straightforward manner. On Sat, Aug 24, 2019 at 8:47 AM Nicholas Krause via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Greetings All, > > I was wondering what projects seem to improve the most from lld as a > linker. It s > > seems to mostly be browsers and games but if someone has something else > > I would be interested to hear what. The site doesn't really talk about what > > projects improve the most so I would be curious to hear what does and > > even if possible why. > > > Nick > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190826/6122fc48/attachment-0001.html>
Hello, to echo others, significant benefits have been seen in link times at Sony PlayStation (turnaround time is really important for the large engineering teams working on games). Multithread utilization in lld is good. Additionally, my experience is that other LLVM features such as LTO and CFI (which requires LTO / Thin LTO) are easier to adopt with lld than alternatives. Finally, the lld code is well structured, easy to follow and leverages other parts of LLVM where sensible. Thanks, Simon On Mon, Aug 26, 2019 at 4:24 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote:> As Eric mentioned, lld is generally much faster than GNU linkers, so many > companies, especially ones that build large-scale programs (including > Google) have migrated to lld and saw a significant reduction in build time, > which improved developer productivity. So I'd say that large-scale program > development seem to improve the most from lld. > > Other interesting area that seem to be benefited from lld is a bootloader > and other UEFI programs. UEFI programs are in COFF file format (which is > the same as Windows), and it was not easy to build a UEFI program in a > host-independent way. There was a hacky way to workaround: for example, you > can first build a UEFI program as an ELF program and transplant its text > and data segments to an empty COFF file using objcopy. Or, maybe you can > just use a Windows machine to link an UEFI program. lld solved the issue > because lld is a cross-linker. You can create COFF object files using > clang-cl and link the object files using lld/COFF to produce a UEFI program > in a very straightforward manner. > > On Sat, Aug 24, 2019 at 8:47 AM Nicholas Krause via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Greetings All, >> >> I was wondering what projects seem to improve the most from lld as a >> linker. It s >> >> seems to mostly be browsers and games but if someone has something else >> >> I would be interested to hear what. The site doesn't really talk about >> what >> >> projects improve the most so I would be curious to hear what does and >> >> even if possible why. >> >> >> Nick >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190827/209ac094/attachment-0001.html>