On Mon, Jul 27, 2015 at 5:52 PM, Reid Kleckner <rnk at google.com> wrote:> 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. >To be clear I understand you: the reason it's usually not sufficient is because most programs use build systems that don't really provide an opportunity for such a step; they assume the compiler only needs to be told about one source file at a time right up until machine code linking time?> 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. >Yes indeed. I understand there is work being done on achieving this by following the usual build procedure, but essentially disguising bitcode files as object files until link time? 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. > > Anyway, for now, llvm-link will do the job, but it isn't really meant to > be a user facing tool. >Right, I'm looking at both whole-program optimisation and static analysis. But I suppose as you say, llvm-link should do the job for now. Hope that explains things. :)>It does, thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150727/09451812/attachment.html>
On Mon, Jul 27, 2015 at 9:59 AM, Russell Wallace <russell.wallace at gmail.com> wrote:> On Mon, Jul 27, 2015 at 5:52 PM, Reid Kleckner <rnk at google.com> wrote: > >> 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. >> > > To be clear I understand you: the reason it's usually not sufficient is > because most programs use build systems that don't really provide an > opportunity for such a step; they assume the compiler only needs to be told > about one source file at a time right up until machine code linking time? >In practice, it's not sufficient because there are usually pre-compiled objects passed into the link step, and symbols from the bitcode are referenced from those object files. Getting the precise list of symbols that are actually referenced externally is a big part of the value of LTO. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150727/467fe6d5/attachment.html>
On Mon, Jul 27, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote:> In practice, it's not sufficient because there are usually pre-compiled > objects passed into the link step, and symbols from the bitcode are > referenced from those object files. Getting the precise list of symbols > that are actually referenced externally is a big part of the value of LTO. >Right, yes, that's a very good point. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150727/2d913371/attachment.html>