[llvm-dev] LLD status update and performance chart

[Rui Ueyama via llvm-dev]

On Fri, Dec 16, 2016 at 12:58 PM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 16 December 2016 at 19:28, Rui Ueyama <ruiu at google.com> wrote:
> > It may be good to compile a wishlist about a linker to collect feature
> ideas
> > people wish to use. I honestly know only one major request: embedding a
> > linker to a program. I guess that this single feature satisfies a
> majority
> > of needs as per 80:20 rule, but I really want to know what people wish to
> > have.
>
> Indeed. Getting a list of what people need and who's committing to do
> those things is a good idea.
>
> At this stage, we should refrain from adding any wild wish, or it'll
> be impossible to do anything.
>
> But given developer involvement in adding functionality as well as
> keeping the promise of stability and performance, a next-steps list is
> a good way to go.
>
>
>
> > I agree with a fine print that I wish people working on LLVM and clang
> aware
> > that best practices in compilers may not be directly transferable to
> > linkers. Linkers and compilers are different kinds of programs.
>
> Wholeheartedly agree!
>
> This is already true for compiler-RT, libc++, the test-suite, polly
> and many other "LLVM branded" projects.
>
>
> > The first thing that comes up to my mind with regard to pushing LLD
> forward
> > as an LLVM project is to move more code to LLVM libraries so that we can
> > make LLD smaller. What do you think?
>
> As you and Rafael have said in this thread, the reusable part of
> linkers is not that big, so having LLD libraries in objdump (for
> example) may not be practical, but having a separate (small) symbol
> handling library that both use could be a potential way forward. I
> don't know enough about LLD or objdump to have any concrete opinion,
> but I have a feeling that objdump is a much bigger program than it
> should be.
>
> People usually say it's because the code is not really reusable. That
> may be true, but if we can find reusability on small tools and LLD,
> that'd at least reduce code a bit. Given that LLD already depends on
> Clang and LLVM, there's no bad side of the increased dependency. (is
> there?).
>

Nope, it doesn't depend on Clang. We uses a lot of LLVM libraries that
Clang depends on, but not on Clang.


> But I would personally follow a more pragmatic approach. It should be
> ok for LLD to have its own infrastructure, as long as it's not
> completely duplicating and increasing maintenance for both LLD and
> LLVM developers.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161216/fdc58da2/attachment.html>