[LLVMdev] LLD improvement plan

[Rui Ueyama]

I think many common parts are already factored out as libObject or libLTO,
so I'm not too worried about that. We should factor out even more and make
linker smaller.

By common model, do you mean we should have a set of common base classes
for all three linkers? I'm not sure if we can do this. I'm not against
that, though. It feels to me that "having a common model makes things
easier" is a unproved hypothesis, and I presented many counter examples
already. At least I believe we can agree that the current model doesn't
work as the one. Maybe the new one can be the one, but we are not sure yet.
I hope it sets a common model, but I'm also okay with sharing less code if
it makes sense overall. We need to experiment. The first try to set a
common model didn't seem successful, at least.

Did you read the existing code and the new one? In general terms, I'd
totally agree with you. What you are saying is a good engineering practice.
However, as I said, I tried hard to refactor that already for months or
maybe over a year continually and came to this kind of depressing
conclusion. If you hack on the existing LLD and the new one, I believe you
would understand the point.

(One interesting story would be that I tried to add LTO to LLD a few months
ago but couldn't make it because it took too much time because of the
complexity (and that was the final push to make me think that was not going
to work), and then Peter came in and wrote up the first LTO patch for the
new COFF linker pretty quickly. Peter knows far more than me about LTO for
sure, but still it means something.)

I believe we should be careful about applying compiler's analogy to
linkers. They are pretty different.

On Fri, May 29, 2015 at 9:06 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> On Fri, May 29, 2015 at 8:29 PM, James Y Knight <jyknight at google.com>
> wrote:
>
>>
>> On May 29, 2015, at 10:08 PM, Rui Ueyama <ruiu at google.com> wrote:
>> > Large part of the difficulties in development of the current LLD comes
>> from over-generalizataion to share code between pretty much different file
>> formats.
>>
>> ISTM the problem that's been described isn't that code is shared between
>> file formats, but that an internal representation was chosen based on what
>> MachO required, which in the end turned out to be unsuitable for
>> representing the greater generality allowed by the other two file formats.
>>
>> You state that the goal is to use this new model for ELF too, assuming it
>> proves itself worthy. Will ELF and COFF not share most of the core of the
>> code at that point?
>>
>> And once COFF and ELF are taken care of, do you not think the new model
>> will be suitable for MachO, too? It seems to me that it ought to be able to
>> handle MachO's needs just fine, with a suitable division of MachO sections
>> into "Chunk"s.
>>
>> Perhaps once everything is said and done, lld can once again have a
>> single core model. I think that may be what Sean was trying to get at --
>> not that it's wrong to create a new model as a base, but that the
>> expectation should be that new model will be _the_ model used in LLD, not a
>> second model to be kept permanently alongside the current
>> "single-symbol-per-atom" model, which has been shown insufficient.
>>
>
> I couldn't have said it better myself.
>
> Looking at the bigger picture, without some sort of commonality factored
> across all 3 formats in LLD, it is very difficult for the LLVM project to
> deliver useful innovations consistently across platforms. Without a common
> model, we are limited to a patchwork of platform-specific hacks; with a
> common model, we can think about new features at a higher level and deliver
> them consistently.
>
> The situation is very analogous to the reason why it is a good idea to
> have the LLVM IR in the middle-end. The LLVM IR is not target-agnostic; but
> the target-specific aspects are managed in more-or-less controlled fashion
> that allows thinking about certain things at a higher level.
>
> -- Sean Silva
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150529/4562b5d8/attachment.html>