<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 27, 2015 at 10:39 AM, Steve King <span dir="ltr"><<a href="mailto:steve@metrokings.com" target="_blank">steve@metrokings.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jul 27, 2015 at 9:52 AM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
<br>
> From the perspective of LTO, we just want users to be able<br>
> to add -flto to their compile and link lines, and make that produce a faster<br>
> executable, without the user ever being aware of the bitcode.<br>
<br>
</span>For targets without GNU binutils and gcc driver support, has this goal<br>
been achieved?  The few times I've tried, Clang's hard-coded<br>
dependencies on host GNU tools block LTO and linked binaries in<br>
general.  For my target, manually running llvm-link and llc is the<br>
only way to get LTO-like output, but otherwise works pretty well.<br>
<br>
For this same reason, I get worried when I hear maintainers state that<br>
llvm-link, llc, llvm-mc, etc are developer only tools.  GNUless<br>
targets use these tools for production code for lack of working<br>
alternatives.<br>
<br>
If there's been recent progress on removing GNU dependencies, I'm all ears.<br></blockquote><div><br></div><div>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.</div></div></div></div>