[FR] Provide a source code revision for prebuilt Android libc++

[serhiihuralniksc]

Description

We'd like to use LTOed libc++ for our projects but unfortunately NDK does not provide IR version of this. Presumably it is not an oversight but rather there are some objective reasons behind it. In this light we plan to build it with LTO ourselves but to be 100% sure it is compatible with the compiler we need to start with the same source code state.

r26 canary has clang_source_info.md. Wondering if this is literally Clang-only or applies to all LLVM components bundled with NDK including libc++? If the former - is it feasible to include some sort of machine-readable description for the source code revision that corresponds to the bundled Android libc++?

[DanAlbert]

r26 canary has clang_source_info.md. Wondering if this is literally Clang-only or applies to all LLVM components bundled with NDK including libc++?

Yes

If the former - is it feasible to include some sort of machine-readable description for the source code revision that corresponds to the bundled Android libc++?

@pirama-arumuga-nainar (the NDK doesn't produce that, it just ships it)

[DanAlbert]

Although getting ahead of the X/Y problem... @pirama-arumuga-nainar, how practical is it to provide an LTO compatible libc++?

[serhiihuralniksc]

@DanAlbert I'm a bit confused - "yes" means it is for compiler only or for everything?

[pirama-arumuga-nainar]

The patches are in a JSON file (toolchain/llvm_android/patches/PATCHES.json) after you follow instructions in https://android.googlesource.com/toolchain/llvm_android/#instructions-to-rebuild-a-particular-toolchain-release to checkout a prebuilt's sources.

The external/toolchain-utils/llvm_tools/patch_manager.py script can then apply the patches to an LLVM source tree. Here is a sample invocation.

[DanAlbert]

Sorry. First message of the day and was pre-coffee. Yes, it's the whole toolchain. See the changelog

Issue 1530: Updated libc++ to match LLVM version.

[pirama-arumuga-nainar]

Although getting ahead of the X/Y problem... @pirama-arumuga-nainar, how practical is it to provide an LTO compatible libc++?

If we're also going to build the libc++.so with LTO, the libc++_static.a would be LLVM IR (ie LTO-compatible) as well. (@rprichard FYI). Non-LTO libc++.so and an LTO libc++_static.a would be extra work.

@serhiihuralniksc How does an LTO-enabled libc++ benefit you? The hot code in libc++ should already be in the headers.

@kongy we don't enable LTO for libcxx on the Android platform. Any particular reason/downsides?

[serhiihuralniksc]

@pirama-arumuga-nainar

How does an LTO-enabled libc++ benefit you? The hot code in libc++ should already be in the headers.

To be clear - we are interested in IR libc++_static.a (implying libc++abi also) to be linked with our projects. There are two reasons:

• expecting more binary size optimizations to be done by the toolchain once we present libc++ as an LLVM IR. It is the last and only non-IR linker input we have
• we have a custom toolchain component that performs IR partitioning of the whole link in order to eventually create a few interconnected DSOs with automatically deduced cross interfaces. Having libc++ in the form of a target machine code requires special handling that we'd like to avoid by making it uniform with the rest of the project (i.e. to make it LLVM IR)

[pirama-arumuga-nainar]

@kongy is evaluating the performance of LTO-enabled libc++ in r.android.com/2623791. Based on the results, we can turn it on for the NDK as well. If you try re-building an LTO-enabled libc++, please share the code-size or performance impact.

[DanAlbert]

(done, since libc++ and LLVM now match)