<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 27, 2015 at 7:24 AM, Russell Wallace <span dir="ltr"><<a href="mailto:russell.wallace@gmail.com" target="_blank">russell.wallace@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Jul 10, 2015 at 11:39 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Fri, Jul 10, 2015 at 3:37 PM Russell Wallace <<a href="mailto:russell.wallace@gmail.com" target="_blank">russell.wallace@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'm trying to figure out exactly what the function and status of the different linking tools is. The impression I get is:</div><div><br></div><div>1. For linking multiple bitcode (either binary or text format) files together, llvm-link is the current and future intended tool.</div><div><br></div><div>2. For converting bitcode files into (machine code) object files, llc is the current and future intended tool.</div><div><br></div></div></blockquote><div><br></div></span><div>llvm-link and llc are developer tools only. clang is designed to be the interface here (or your language specific driver).</div></div></div></blockquote><div><br></div></span><div>Okay so for linking bitcode files together, what's the intended command? That is, 'clang x.bc y.bc' will generate an executable, but for generating a single larger bitcode file? Adding -emit-llvm gives an error unless you also add -c, but that just rewrites the original small bitcode files?<br></div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">I think your original description of the situation is accurate. llvm-link will take multiple bitcode files and spit out a big ball o' bitcode, but that's usually not sufficient for LTO, which is the main use case that we want to support. 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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If your use case (static analysis, maybe?) requires the intermediate bitcode, we don't yet have a nice way to get that from clang and maybe we should add one. Maybe -emit-llvm on a link line like you suggested, but that discards information about non-bitcode object files.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anyway, for now, llvm-link will do the job, but it isn't really meant to be a user facing tool.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Hope that explains things. :)</div></div>