llvm dev - Jun 2021 - RFC: Revisiting LLD-as-a-library design

As one of the people working on the new Mach-O backend, my main concerns are:

  1.  The Mach-O backend is still very much in flux, and will likely remain so
until the end of this year. Whoever undertakes this library-fication should sync
up with us to avoid e.g. awkward merge conflicts.
  2.  Performance is very important to us, and this library-fication should not
regress it. Right now, we don't have a good benchmarking service set up (the
LNT server only benchmarks LLD-ELF); we've been mostly just profiling things
locally. I can send these benchmarking instructions to whomever takes on this
effort.

Jez
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210611/788f0053/attachment.html>

To second what Jez said here: the new Mach-O backend is still pretty young (e.g.
it wasn’t even the default Mach-O backend in LLVM 12). It’s being actively
developed, and there’s still the possibility of fairly invasive changes being
required to support new features or as we gain more implementation experience.

One of our main motivations for LLD for Mach-O was to improve incremental build
speeds for our developers. We’ve found that link speed is a major component of
incremental build times; LLD’s speed is a huge win there, and we care a lot
about maintaining that speed. I’m CCing Nico, since he’s also been actively
benchmarking LLD for Mach-O against Chromium builds (and reporting and fixing
speed regressions).

Reid’s proposals (better error handling and eliminating globals) are completely
reasonable. In general though, I really appreciate the LLD codebase’s simplicity
and think it’s very valuable for understanding and maintaining the code. I
haven’t worked too much with the rest of LLVM or Clang, so I’m not at all trying
to compare LLD with them or cast aspersions on those codebases; I’m just
speaking from my personal perspective. For example, having (mostly) separate
codebases for each LLD port set off my “code duplication” spidey senses when I
first started working with LLD, but while it does lead to some amount of
duplication, there’s also a lot of subtle behavior differences between
platforms, and having some amount of duplication is IMO a better tradeoff than
e.g. having common functions that have a bunch of conditionals for each
platform, or trying to come up with common abstract interfaces that are
specialized for each platform, or so on. I really hope we can maintain that
simplicity to whatever extent possible.

Thanks,
Shoaib

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Jez Ng
via llvm-dev <llvm-dev at lists.llvm.org>
Reply-To: Jez Ng <jezng at fb.com>
Date: Friday, June 11, 2021 at 2:14 PM
To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: Revisiting LLD-as-a-library design

As one of the people working on the new Mach-O backend, my main concerns are:

  1.  The Mach-O backend is still very much in flux, and will likely remain so
until the end of this year. Whoever undertakes this library-fication should sync
up with us to avoid e.g. awkward merge conflicts.
  2.  Performance is very important to us, and this library-fication should not
regress it. Right now, we don't have a good benchmarking service set up (the
LNT server only benchmarks LLD-ELF); we've been mostly just profiling things
locally. I can send these benchmarking instructions to whomever takes on this
effort.
Jez
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210612/19207d4f/attachment-0001.html>