[LLVMdev] LLD improvement plan

[Sean Silva]

On Mon, May 4, 2015 at 12:52 PM, Chris Lattner <clattner at apple.com> wrote:

> On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote:
>
> *Proposal*
>
>    1. Re-architect the linker based on the section model where it’s
>    appropriate.
>    2. 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 compatibility.
>
> - 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
> goal.
>
>
> 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.
>

I don't think this is correct.

The only reason we should be having a major split along Camp A and Camp B
like you describe is in the face of a concrete "compatibility" feature that
*absolutely cannot* be implemented without sacrificing a modular,
library-based, well-architected design. That is not what this thread is
about, so I don't think your split is accurate.

I think it has merely been *forgotten* that it would be useful to have an
infrastructure rather than "main() in a library", or even "main() in a
separate binary"!. This is the LLVM ethos (as I'm sure you know far better
than I ;).

Both LLVM and Clang prove that hard problems with significant
"compatibility" concerns can be tackled and top-tier in-production QoI
achieved while still upholding a high standard of external reusability that
allows novel uses. Given what LLVM and Clang have been able to absorb (x86
ISA? C++? MSVC inline asm?) without fundamentally destabilizing their
modular design, I think that we can do a bit better with LLD before
throwing in the towel and cleaving it into a "compatibility" and "shiny"
part.

-- Sean Silva


>  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
> compatibility.
>
> 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 me.
>
> 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?
>
> -Chris
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150528/be1c43e0/attachment.html>