llvm dev - Jul 2015 - [LLVMdev] Linking tools

On Mon, Jul 27, 2015 at 9:52 AM, Reid Kleckner <rnk at google.com> wrote:
> From the perspective of LTO, we just want users to be able
> to add -flto to their compile and link lines, and make that produce a
faster
> executable, without the user ever being aware of the bitcode.
For targets without GNU binutils and gcc driver support, has this goal
been achieved?  The few times I've tried, Clang's hard-coded
dependencies on host GNU tools block LTO and linked binaries in
general.  For my target, manually running llvm-link and llc is the
only way to get LTO-like output, but otherwise works pretty well.

For this same reason, I get worried when I hear maintainers state that
llvm-link, llc, llvm-mc, etc are developer only tools.  GNUless
targets use these tools for production code for lack of working
alternatives.

If there's been recent progress on removing GNU dependencies, I'm all
ears.

Cheers,
-steve

On Mon, Jul 27, 2015 at 10:39 AM, Steve King <steve at metrokings.com>
wrote:
> On Mon, Jul 27, 2015 at 9:52 AM, Reid Kleckner <rnk at google.com>
wrote:
>
> > From the perspective of LTO, we just want users to be able
> > to add -flto to their compile and link lines, and make that produce a
> faster
> > executable, without the user ever being aware of the bitcode.
>
> For targets without GNU binutils and gcc driver support, has this goal
> been achieved?  The few times I've tried, Clang's hard-coded
> dependencies on host GNU tools block LTO and linked binaries in
> general.  For my target, manually running llvm-link and llc is the
> only way to get LTO-like output, but otherwise works pretty well.
>
> For this same reason, I get worried when I hear maintainers state that
> llvm-link, llc, llvm-mc, etc are developer only tools.  GNUless
> targets use these tools for production code for lack of working
> alternatives.
>
> If there's been recent progress on removing GNU dependencies, I'm
all ears.
>
Basically, LTO for projects that have pre-compiled objects requires
integration with a real static linker. Currently we use plugins to
integrate with binutils linkers, Mac ld64, and some other closed-source
linkers. To cut this dependency, we need a new linker, which is what LLD is
intended to become.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150727/de163d76/attachment.html>

On Mon, Jul 27, 2015 at 10:55 AM, Reid Kleckner <rnk at google.com>
wrote:
> On Mon, Jul 27, 2015 at 10:39 AM, Steve King <steve at
metrokings.com> wrote:
>>
>> If there's been recent progress on removing GNU dependencies,
I'm all
>> ears.
>
> Basically, LTO for projects that have pre-compiled objects requires
> integration with a real static linker. Currently we use plugins to
integrate
> with binutils linkers, Mac ld64, and some other closed-source linkers. To
> cut this dependency, we need a new linker, which is what LLD is intended to
> become.
Thanks and yes, I eagerly await Clang's switch to lld.  Clang also
calls the gcc driver though, at least to invoke collect2.  Will lld
allow clang to remove all GNU dependencies?