llvm dev - Dec 2016 - LLD status update and performance chart

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?).

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

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>

On 16 December 2016 at 21:15, Rui Ueyama <ruiu at google.com>
wrote:
> Nope, it doesn't depend on Clang. We uses a lot of LLVM libraries that
Clang
> depends on, but not on Clang.
Ah, I stand corrected! I can't see what LLD would need to share with
Clang anyway. :)

--renato