llvm dev - Jan 2017 - libLTO C API stability policy

Hi all,

libLTO is exposing a very “stable” (in the sense of immutable) C API to be used
by linkers (and binutils tools) that manipulate bitcode (like when performing
LTO).

I’m looking into relaxing the stability concern and design a policy for this API
that would allow to deprecate and remove some the APIs exposed here. The MacOS
linker (ld64) is one the users of libLTO, but there are others (Sony? Qualcomm?
Anyone else?) that I think are also targeting this API.

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!

Thanks,

— 
Mehdi

Some of the macOS tools like nm also use libLTO to symbolicate bitcode.

CCing Kevin who owns these and will know the API in use.

Thanks,
Pete
> On Sep 30, 2016, at 1:18 PM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi all,
> 
> libLTO is exposing a very “stable” (in the sense of immutable) C API to be
used by linkers (and binutils tools) that manipulate bitcode (like when
performing LTO).
> 
> I’m looking into relaxing the stability concern and design a policy for
this API that would allow to deprecate and remove some the APIs exposed here.
The MacOS linker (ld64) is one the users of libLTO, but there are others (Sony?
Qualcomm? Anyone else?) that I think are also targeting this API.
> 
> 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!
> 
> Thanks,
> 
> — 
> Mehdi
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi Mehdi,
Sony is using C API.
Please keep us in the loop!
Katya.

> -----Original Message-----
> From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com]
> Sent: Friday, September 30, 2016 1:19 PM
> To: llvm-dev
> Cc: Romanova, Katya; Sergei Larin
> Subject: libLTO C API stability policy
> 
> Hi all,
> 
> libLTO is exposing a very “stable” (in the sense of immutable) C API to be
> used by linkers (and binutils tools) that manipulate bitcode (like when
> performing LTO).
> 
> I’m looking into relaxing the stability concern and design a policy for
this API
> that would allow to deprecate and remove some the APIs exposed here.
> The MacOS linker (ld64) is one the users of libLTO, but there are others
> (Sony? Qualcomm? Anyone else?) that I think are also targeting this API.
> 
> 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!
> 
> Thanks,
> 
> —
> Mehdi
>

Hello Mehdi,

Sorry for the delayed reply I was out on vacation for that last few days.

As Pete Cooper already commented, the Apple cctools project (aka the “binutils”
stuff), make use of the libLTO C API.

At this time do you want to know an exact list of each API in use?  It is not
clear from your email below exactly what you are after at this point in time
other than to identify who are the stakeholders.  On that I do care about the
libLTO C API so we don’t break the uses in the Apple cctools project.

Kev
> On Sep 30, 2016, at 1:18 PM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi all,
> 
> libLTO is exposing a very “stable” (in the sense of immutable) C API to be
used by linkers (and binutils tools) that manipulate bitcode (like when
performing LTO).
> 
> I’m looking into relaxing the stability concern and design a policy for
this API that would allow to deprecate and remove some the APIs exposed here.
The MacOS linker (ld64) is one the users of libLTO, but there are others (Sony?
Qualcomm? Anyone else?) that I think are also targeting this API.
> 
> 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!
> 
> Thanks,
> 
> — 
> Mehdi
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi Kevin,
> On Oct 3, 2016, at 10:49 AM, Kevin Enderby <enderby at apple.com>
wrote:
> 
> Hello Mehdi,
> 
> Sorry for the delayed reply I was out on vacation for that last few days.
> 
> As Pete Cooper already commented, the Apple cctools project (aka the
“binutils” stuff), make use of the libLTO C API.
> 
> At this time do you want to know an exact list of each API in use?  It is
not clear from your email below exactly what you are after at this point in time
other than to identify who are the stakeholders.  On that I do care about the
libLTO C API so we don’t break the uses in the Apple cctools project.
I’d like to establish a windows of deprecation of APIs.
I assume that Apple’s binutils and ld64 have the same constraint/use-cases (but
maybe I’m missing something).

Right now I’m more interested to collect the non-Apple (non-DT) users and their
constraints ;-)

Thanks,

— 
Mehdi


> 
>> On Sep 30, 2016, at 1:18 PM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>> Hi all,
>> 
>> libLTO is exposing a very “stable” (in the sense of immutable) C API to
be used by linkers (and binutils tools) that manipulate bitcode (like when
performing LTO).
>> 
>> I’m looking into relaxing the stability concern and design a policy for
this API that would allow to deprecate and remove some the APIs exposed here.
The MacOS linker (ld64) is one the users of libLTO, but there are others (Sony?
Qualcomm? Anyone else?) that I think are also targeting this API.
>> 
>> 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!
>> 
>> Thanks,
>> 
>> — 
>> Mehdi
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/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

Thanks Petr, 

Good to know :)

— 
Mehdi
> On Jan 29, 2017, at 7:35 AM, Petr Pavlu <petr.pavlu at arm.com>
wrote:
> 
>> 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

Hi Mehdi,

Just saw the recent replies to this old thread, so just as an FYI... We 
(QuIC Hexagon and ARM) are moving away from libLTO and are anticipating 
to complete the move to the C++ API imminently, so I don't have any 
particular concerns about backward compatibility of the C API on our side.

Thanks,
Tobias

On 09/30/2016 03:18 PM, Mehdi Amini via llvm-dev wrote:
> Hi all,
>
> libLTO is exposing a very “stable” (in the sense of immutable) C API to be
used by linkers (and binutils tools) that manipulate bitcode (like when
performing LTO).
>
> I’m looking into relaxing the stability concern and design a policy for
this API that would allow to deprecate and remove some the APIs exposed here.
The MacOS linker (ld64) is one the users of libLTO, but there are others (Sony?
Qualcomm? Anyone else?) that I think are also targeting this API.
>
> 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!
>
> Thanks,
>
> —
> Mehdi
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.