[LLVMdev] Updated RFC: ThinLTO Implementation Plan

[Dave Bozier]

> 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.

> 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.

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.