Features Download
From: Chris Lattner <clattner <at> apple.com>
Subject: Re: LLD improvement plan
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Monday 4th May 2015 19:52:55 UTC (over 3 years ago)
On May 1, 2015, at 12:31 PM, Rui Ueyama  wrote:
> Proposal
> Re-architect the linker based on the section model where it’s
> Stop simulating different linker semantics using the Unix model. Instead,
directly implement the native behavior.

Preface: I have never personally contributed code to LLD, so don’t take
anything I’m about to say too seriously.  This is not a mandate or
anything, just an observation/idea.

I think that there is an alternative solution to these exact same problems.
 What you’ve identified here is that there are two camps of people
working on LLD, and they have conflicting goals:

- Camp A: LLD is infrastructure for the next generation of awesome linking
and toolchain features, it should take advantage of how compilers work to
offer new features, performance, etc without deep concern for

- Camp B: LLD is a drop in replacement system linker (notably for COFF and
ELF systems), which is best of breed and with no compromises w.r.t. that

I think the problem here is that these lead to natural and inescapable
tensions, and Alex summarized how Camp B has been steering LLD away from
what Camp A people want.  This isn’t bad in and of itself, because what
Camp B wants is clearly and unarguably good for LLVM.  However, it is also
not sufficient, and while innovation in the linker space (e.g. a new
“native” object file format generated directly from compiler
structures) may or may not actually “work” or be “worth it”, we
won’t know unless we try, and that won’t fulfill its promise if there
are compromises to Camp B.

So here’s my counterproposal: two different linkers.

Lets stop thinking about lld as one linker, and instead think of it is two
different ones.  We’ll build a Camp B linker which is the best of breed
section based linker.  It will support linker scripts and do everything
better than any existing section based linker.  The first step of this is
to do what Rui proposes and rip atoms out of the model.

We will also build a no-holds-barred awesome atom based linker that takes
advantage of everything it can from LLVM’s architecture to enable
innovative new tools without worrying too much about backwards

These two linkers should share whatever code makes sense, but also
shouldn’t try to share code that doesn’t make sense.  The split between
the semantic model of sections vs atoms seems like a very natural one to

One question is: does it make sense for these to live in the same lld
subproject, or be split into two different subprojects?  I think the answer
to that question is driven from whether there is shared code common between
the two linkers that doesn’t make sense to sink down to the llvm
subproject itself.

What do you think?

CD: 4ms