[llvm-dev] RFC: Revisiting LLD-as-a-library design

[Nico Weber via llvm-dev]

+1 to the concerns here.

Not too surprisingly the concerns are from people who actually work on lld
[1], who are likely to value hackability. I'd argue that hackability for
people working on lld is ultimately beneficial for users of lld too though.

> I think the important thing is that we've established a direction. If you
> review LLD code, consider reviewing and accepting patches that move in
this
> direction.

I'm not surprised that users of a software packet agree on having the
people writing that software do more work. I don't think that necessarily
counts as establishing a direction though.


1: ("1 year" chosen arbitrarily, but doesn't change much with "2 years")
$ git shortlog -nes lld --since '1 year ago' | head
   248 Jez Ng <jezng at fb.com>
   167 Fangrui Song <i at maskray.me>
   134 Nico Weber <thakis at chromium.org>
    69 Sam Clegg <sbc at chromium.org>
    41 Greg McGary <gkm at fb.com>
    29 Martin Storsjö <martin at martin.st>
    26 Reid Kleckner <rnk at google.com>
    22 Vy Nguyen <vyng at google.com>
    21 Petr Hosek <phosek at google.com>
    20 Georgii Rymar <grimar at accesssoftek.com>

On Sat, Jun 12, 2021 at 2:55 AM Shoaib Meenai <smeenai at fb.com> wrote:

> 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/20210616/a33a1d5a/attachment.html>