[llvm-dev] LLD status update and performance chart

[Rafael Avila de Espindola via llvm-dev]

>> 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.

> 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