[PATCH] Add -l option to llvm-link and allow linking by resolving symbols

[Mekhanoshin, Stanislav]

This is in fact an extraction from such a tool into a more general interface. If no one else needs this I do not insist anyway.
BTW, I do remember that Borland linker a while ago was doing such a thing. This is purely an optimization and in our case this allows to speed up compilation by dropping unneeded stuff before IPO.

Stas


-----Original Message-----
From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] 
Sent: Friday, April 25, 2014 10:15 PM
To: Mekhanoshin, Stanislav
Cc: reviews+D3459+public+156625a4405c5834 at reviews.llvm.org; Arsenault, Matthew; llvm-commits
Subject: Re: [PATCH] Add -l option to llvm-link and allow linking by resolving symbols

On 25 April 2014 14:05, Mekhanoshin, Stanislav <Stanislav.Mekhanoshin at amd.com> wrote:
> The "smart linking" is not a completely new concept for native linkers, even if library is organized in an archive. A big translation unit may have many symbols with just a few really needed. Even if we change our own libraries we could not stop developers from building large modules. Probably adding this as a mode for core linker would be not a best idea, but having this as a separate tool seems to be a good idea at least for me, especially if we already have this code.

What native linkers have for this is

* Support for libraries (.a, .lib). The semantic is that a member is fetched only if it is needed.
* Some GC support (in a very broad sense). This includes things like comdats, ld64's atoms and section gc in gold. The semantic is
different: the entire file is fetched, but parts of it can be dropped if they are found to be unnecessary.

There are some peculiar corner cases in these. For example, my understanding is that for ELF the files are treated in order, for macho all .o are handled before all .a.

It looks like you have a tool X that needs a third model, where parts of a single object are only fetched if they are needed. If that is the case, that logic should probably live in tool X, not lib/Linker.

Cheers,
Rafael