[LLVMdev] Updated RFC: ThinLTO Implementation Plan

[Xinliang David Li]

On Wed, Jun 3, 2015 at 9:54 AM, Dave Bozier <seifsta at gmail.com> wrote:

> > Ok, I see. Does it help that there are LTOModule (lto_module_* in the
> > C API) interfaces for checking if a file contains bitcode (regardless
> > of whether it is straight-up or native-wrapped)?
>
> Unfortunately no it won't help. We try to identify inputs on the
> command line in the order 1) Object 2) static library 3) Bitcode 4)
> Linker script. Our LTO implementation is split into a separate process
> that is lazily loaded only in the case that we are trying to identify
> an input and don't recognize it as an object or static library and
> suspect it is a bitcode file.
>
>
This sounds a little fragile and inflexible. How is the command line formed?




> > I don't know how hard
> > in your linker it is to query these when deciding whether to treat the
> > object file as bitcode or not, or how hard it is to pass the resulting
> > object file along to the libLTO routines for handling (they
> > automatically handle the native-wrapped object files so the linker
> > shouldn't have to do anything special to read them).
>
> It will be difficult with our current design and without compromise.
> Either we change our Identify routines to process the section headers
> (can be costly for COMDAT heavy code or code built with
> -ffuntion-sections, --fdata-sections). Or we change our ELF scan
> routines to specially identify and handle ELF with llvmbc differently.
>
>
At least for ELF, there is a e_machine field in the Elf header that can
potentially be useful here.


thanks,

David


Alternatively could we mark the native file header in a way that
> identifies it as a bitcode wrapper is an option? That way we wouldn't
> need to parse the section headers upfront to identify how the input
> should be treated. This is possibly something we can look at as a
> private change.
>
> > Specifically, in the C API these are the lto_module_is_object_file*
> > variants, which will return true for either straight-up or
> > native-wrapped bitcode. All of the mechanics of handling bitcode vs
> > native object-wrapped bitcode are down in the IRObjectFile handling.
> > So the LTOModule:isBitcode*/lto_module_is_object_file* will correctly
> > identify native object-wrapped bitcode as bitcode. And the
> > LTOModule::createFrom*/lto_module_create* routines correctly parse the
> > native object-wrapped bitcode and return an LTOmodule.
>
> It's great to see these API functions have been considered and added
> to libLTO and I'm sure they will help for other tools. Unfortunately
> not ours.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150603/644ce39c/attachment.html>