[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>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Rui Ueyama" <ruiu at google.com>
> Sent: Tuesday, December 13, 2016 2:50:51 PM
> Subject: Re: [llvm-dev] LLD status update and performance chart
> 
> >> 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.
> 
> If it is possible, sure. Even if the JIT design is suboptimal, it
> would
> be nice if didn't involve coding their own .o relocation processing.
> 
> The first time I implemented relocation processing in lld I actually
> had
> an eye at sharing the code. It was even in our internal project
> management bullet list and assigned to me by my request.
> 
> As I learned as I implemented more and more of lld, the actual
> application of relocations is small part of the linker interaction. A
> big part is deciding about relaxations, copy relocations, gots and
> plts,
> so I rewrote the relocation handling in its current form (r266158).
> That
> involves saving information during the first of two passes over the
> relocations. I really don't think that that is what the JIT wants.

This is definitely a good point. We'll need to think about how this when someone gets time to look at it again.

Thanks again,
Hal

> 
> > 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).
> 
> That is exactly my impression, but I am only working on lld, not in
> the
> JIT, so it is hard to show it. The current design needs to apply
> regular
> .o relocations, which is unfortunate, but not much more of the
> linker.
> 
> Don't let that or my previous failure block you. If you have a patch
> to
> share the relocation processing code that doesn't compromise lld,
> please
> send a patch.
> 
> Cheers,
> Rafael
> 

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