[llvm-dev] libLTO C API stability policy

[Petr Pavlu via llvm-dev]

> From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
> Sent: Friday, September 30, 2016 1:19 PM
>
> I’d like to identify stakeholders so that we can establish a
> new policy that would accomodate everyone as much as possible.
> So if you care about the libLTO C API, please speak-up!

Hi Mehdi,

Apologies, I missed this thread. Thanks for pinging James Molloy
who made me aware of it.

ARM Compiler 6 [1] ships with a home-grown linker (armlink) that
makes use of libLTO and its C API to enable the LTO functionality
in this product.

The installation of the product comes with the libLTO binary and
the only supported use case is to use armlink and libLTO from the
same installation. This means that deprecation and later removing
some functions should not bring us much trouble as long there is
a reasonable window that allows us to update our code to use
newer APIs.

The following is a list of functions that the linker currently
uses:
* lto_get_error_message(),
* lto_module_create_in_local_context(),
* lto_module_create_in_codegen_context(),
* lto_module_dispose(),
* lto_module_get_num_symbols(),
* lto_module_get_symbol_name(),
* lto_module_get_symbol_attribute(),
* lto_codegen_set_diagnostic_handler(),
* lto_codegen_create(),
* lto_codegen_dispose(),
* lto_codegen_add_module(),
* lto_codegen_set_pic_model(),
* lto_codegen_set_cpu(),
* lto_codegen_add_must_preserve_symbol(),
* lto_codegen_compile(),
* lto_codegen_compile_to_file(),
* lto_codegen_debug_options().

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.comp6/index.html

Thanks,
Petr