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

On 16 December 2016 at 18:15, Rui Ueyama via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> So, correct me if I'm wrong, but I don't see no serious conflicts
here. The
> conflict I saw in the thread is I believe superficial, and I strongly
> believe that it could have been addressed calmly and nicely if we have used
> more words to explain thoughts instead of small number of strong words.
Hi Rui,

Thank you for your comments. I agree with your views that the issue
was much more about communication than technical. It's how things are
said, rather that what is said, and we should put that aside.

On the technical side, I agree that the project needs a solid base
before fancy new features get incorporated, but I also believe that
parallel development, even on trunk, can happen as it does in LLVM
(see GlobalISel, pass managers, register allocators, back-ends).

I'm very happy that LLD works well on AArch64, bootstrapping Clang and
passing the test-suite. We aim to reach the same objective next year
on ARM, and go beyond. I'm also happy that the FreeBSD community is
looking at it with serious eyes and trying to make it the default
linker on x86_64.

In the interest of collaboration, I think we should set some goals for
the project in general, getting feedback from the community that works
in it and the stakeholders, at least until we reach production quality
in one architecture. From my point of view, having LLD as the default
linker for FreeBSD/ELF/x86_64 is a strong indication that it "works
well in a large range of situations". I'd happily call that stage
"Production Beta". But that's not all. We need other architectures
(AArch64 and ARM will probably come next), as well as different object
formats (COFF, MachO) to be able to call it "Production Stable".

However, my humble opinion is that we don't need to be in "Production
Stable" to start adding new features, especially when that means a
larger portion of the LLVM ecosystem will begin to contribute more to
the project. Those new features can stay disabled by default and be
isolated from the main code, like we do in LLVM. Yes, that will mean
more work for all of us. Yes, that will mean longer test cycles, more
test configurations. But that will also mean more people working on
it, validating in ways you didn't even know it was possible. That
value is worth the extra trouble, IMVHO, and LLVM's success is living
proof of that.

LLD may be a separate project, and a young one full of energy, but it
is also an "LLVM Project". As such, it's bound to the same level
of
design goals that all LLVM projects share. Not all share all values,
but two that we share amongst all projects is collaboration and
modularisation. Those values reflect our multiple ranges of users and
developers as well as the need to re-use code above raw performance.

As was said in this list, Clang is not faster than GCC for a long
time, even though it was one of the shiny distinctions. The faster the
code we produce, the slower the compiler runs. It's an obvious
relationship, and one that will (hopefully) happen with the linker if
it has any expectation of being used by the whole community, not just
the limited number of developers today.

cheers,
--renato

On Fri, Dec 16, 2016 at 10:45 AM, Renato Golin <renato.golin at
linaro.org>
wrote:
> On 16 December 2016 at 18:15, Rui Ueyama via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > So, correct me if I'm wrong, but I don't see no serious
conflicts here.
> The
> > conflict I saw in the thread is I believe superficial, and I strongly
> > believe that it could have been addressed calmly and nicely if we have
> used
> > more words to explain thoughts instead of small number of strong
words.
>
> Hi Rui,
>
> Thank you for your comments. I agree with your views that the issue
> was much more about communication than technical. It's how things are
> said, rather that what is said, and we should put that aside.
>
> On the technical side, I agree that the project needs a solid base
> before fancy new features get incorporated, but I also believe that
> parallel development, even on trunk, can happen as it does in LLVM
> (see GlobalISel, pass managers, register allocators, back-ends).
>
> I'm very happy that LLD works well on AArch64, bootstrapping Clang and
> passing the test-suite. We aim to reach the same objective next year
> on ARM, and go beyond. I'm also happy that the FreeBSD community is
> looking at it with serious eyes and trying to make it the default
> linker on x86_64.
>
> In the interest of collaboration, I think we should set some goals for
> the project in general, getting feedback from the community that works
> in it and the stakeholders, at least until we reach production quality
> in one architecture. From my point of view, having LLD as the default
> linker for FreeBSD/ELF/x86_64 is a strong indication that it "works
> well in a large range of situations". I'd happily call that stage
> "Production Beta". But that's not all. We need other
architectures
> (AArch64 and ARM will probably come next), as well as different object
> formats (COFF, MachO) to be able to call it "Production Stable".
>
> However, my humble opinion is that we don't need to be in
"Production
> Stable" to start adding new features, especially when that means a
> larger portion of the LLVM ecosystem will begin to contribute more to
> the project. Those new features can stay disabled by default and be
> isolated from the main code, like we do in LLVM. Yes, that will mean
> more work for all of us. Yes, that will mean longer test cycles, more
> test configurations. But that will also mean more people working on
> it, validating in ways you didn't even know it was possible. That
> value is worth the extra trouble, IMVHO, and LLVM's success is living
> proof of that.
>
Currently, as you know, we are working on as-needed basis. There are people
working on AArch64, MIPS, FreeBSD, performance optimization, code
maintainability, better error reporting, etc. We opened many fronts already
because people wish to work on these fronts, so there should be nothing
prevents us from adding one or two more.

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.

LLD may be a separate project, and a young one full of energy, but
it
> is also an "LLVM Project". As such, it's bound to the same
level of
> design goals that all LLVM projects share. Not all share all values,
> but two that we share amongst all projects is collaboration and
> modularisation. Those values reflect our multiple ranges of users and
> developers as well as the need to re-use code above raw performance.
>
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. They are
not that different than, say, clang and llvm-objdump, but the two are still
different for sane reasons. In terms of size, LLD will never become as
large as LLVM or Clang and will stay one or two orders of magnitude smaller
than them. Naturally a lot of things can be different. Therefore, "because
we do that in LLVM or clang" is not that convincing unless it also mention
that it also makes sense in the linker's context. (Renato, I know you are
not saying that.)

We already owe a lot to the main LLVM project. The reason why LLD is small
and easy to maintain is partly because it uses libObject, libSupport, ADT
and libLTO (and in that sense it's already modularized into small pieces).
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 was said in this list, Clang is not faster than GCC for a
long
> time, even though it was one of the shiny distinctions. The faster the
> code we produce, the slower the compiler runs. It's an obvious
> relationship, and one that will (hopefully) happen with the linker if
> it has any expectation of being used by the whole community, not just
> the limited number of developers today.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161216/0ae6e280/attachment.html>

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