[llvm-dev] LLD status update and performance chart

[Andrew Kelley via llvm-dev]

On Tue, Dec 13, 2016 at 3:30 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > On Tue, Dec 13, 2016 at 1:06 PM, Rui Ueyama via llvm-dev <
> > llvm-dev at lists.llvm.org> wrote:
> >>
> >> That said, I think the current our "API" to allow users call our
> linker's
> >> main function hit the sweet spot. I know at least a few LLVM-based
> language
> >> developers who want to eliminate external dependencies and embed a
> linker
> >> to their compilers. That's a reasonable usage, and I think allowing
> them to
> >> pass a map from filename to MemoryBuffer objects makes sense, too. That
> >> would be done without affecting the overall linker architecture. I don't
> >> oppose to that idea, and if someone wrote a patch, I'm fine with that.
> >>
> >
> > As an LLVM-based language developer, this is exactly what I want to do.
> In
> > short:
> >
> >  * Avoid depending on an external binary
> >  * Avoid a fork+exec
> >  * Avoid unnecessary use of the filesystem
> >
> > Does this feature compromise progress on the linker binary?
> >
> > Would it be reasonable for this feature to exist in the next minor
> version
> > release of lld?
>
> I would please ask for it to wait. It requires designing how the linker
> script parser and the thin archive system will fetch new files as they
> are found.
>

That sounds fair. I'm thankful for all the hard work the LLD team is
putting into the project, and it's not my place to demand any features.


> Also, please consider what is so bad about writing a file. If your
> language has anything like translation unites than most of the program
> should already be in .o files.
>

I see your point. It's true that "Avoid unnecessary use of the filesystem",
while still a correct way to design software, is the least important of
those three points. "Avoid depending on an external binary" is most of what
I want to get out of the LLD project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/83565316/attachment.html>