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

[pawel k. via llvm-dev]

Agree here duplication is less of problem than
gnuish/fsfish/binutilish/gccish spaghetti code with no abstractions etc.
and thousands of conditionals etc.

- pawel

sob., 12.06.2021, 08:55 użytkownik Shoaib Meenai via llvm-dev <
llvm-dev at lists.llvm.org> napisał:

> 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
> _______________________________________________
> 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/20210612/33a12f5d/attachment.html>