[llvm-dev] LLD status update and performance chart

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Rafael Avila de Espindola" <rafael.espindola at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "Rui Ueyama" <ruiu at google.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Tuesday, December 13, 2016 2:13:49 PM
> Subject: Re: [llvm-dev] LLD status update and performance chart
> 
> Hal Finkel <hfinkel at anl.gov> writes:
> >
> >> Please tell me what you think about how reusable components would
> >> be
> >> like. Which parts of the linker can be reusable components? Is
> >> that
> >> really feasible?
> > As far as I'm concerned, your response, "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" is perfectly appropriate. We
> > need to guide these discussions with use cases, and that's the use
> > case that's been provided so far.
> >
> > Longer term, we also should take a serious look at how to unify the
> > functionality in LLD with that in our JIT runtime linker. Having
> > two linkers in the LLVM project, one for use with the JIT and one
> > for other things, seems suboptimal.
> 
> In my opinion having a general linker in the JIT is sub optimal. We
> should not be desiginig lld around an idea there is not even a
> consensus

I think there is consensus on not wanting duplicate functionality between LLD and lib/ExecutionEngine. That does not mean that the JIT needs a general linker, but that whatever functionality is common is refactored in a such a way that separate implementations of the same functionality are not required.

Now maybe the JIT's linking functionality should be so different from what LLD does that there's no overlap, but I think that a lot of assumed that there was significant overlap (at least as things currently stand).

 -Hal

> to. And even if it is case that having a general linker is the best
> way
> to write a JIT (I would love to know why a JIT needs something that
> handles copy relocations), we will not be able to evaluate the trade
> offs with the stand alone lld until we finished it.
> 
> Cheers,
> Rafael
> 

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory