What is the point of marker bitcode (-fembed-bitcode-marker)?

user_1087576 0
Viewed 776

This comes up a lot in Apple development—when submitting to the app store with bitcode you must of course include the full bitcode (-fembed-bitcode). But what is the reason for having this intermediate "marker" mode, which includes the sections but not the bitcode itself? There must be some reason why this exists, and why it's often turned on for debug builds.

llvm xcode ios
1 Answers

The point is to make your build faster during development.

Source: You can read through the code reviews of the commits adding the embed-bitcode flags to the clang compiler frontend for further details:

  • Introduce -fembed-bitcode driver option

    This is the clang driver part of the change to embedded bitcode. This includes:

    1. -fembed-bitcode option which breaks down the compilation into two stages. The first stage emits optimized bitcode and the second stage compiles bitcode into object file.

    2. -fembed-bitcode-marker option which doesn't really break down to two stages to speedup the compilation flow.

    3. pass the correct linker flag to darwin linker if tool chains supports embedded bitcode.

  • Embed bitcode in object file (clang cc1 part)

    marker only mode is used to speed up the compilation while still producing enough information in the final output to check if all the files are containing a bitcode section. -fembed-bitcode option will split the compilation into two stages and it adds measurable costs to compile time due to the extra process launch, the serialization and the verifier. -fembed-bitcode-marker is just a way to avoid that costs but still mark the section for the sanity check later (done by linker in our case).

Context: A Guardsquare blog article discusses bitcode enabled builds. The relevant remarks are:

What does Apple do with the embedded bitcode?

The question remains: why does Apple offer the option to embed bitcode? The answer is straightforward. With the bitcode embedded in the executable, Apple is able to recompile applications without interacting with the developer. This has a lot of advantages.

  1. Apple is continuously enhancing the optimization performed by the Clang compiler to further improve the performance of mobile applications and reduce their size. Using the embedded bitcode, Apple itself can recompile applications using the latest, improved version of the compiler. This frees app developers from the burden of continuously having to update their development environment and recompile and reupload their applications to benefit from the latest improvements.

  2. By embedding the bitcode, developers enable Apple to migrate their applications to new types of devices. The embedded bitcode enables Apple to recompile existing applications and make them compatible with the chipsets of new devices.

If you're just debugging and/or testing your app you will not be doing any of the above things. So why waste time and resources actually including the bitcode, when you really just want to make sure everything builds and runs correctly? The embed-bitcode-marker flag is therefore enabled in order to fake this part of the build-process during development.

user_130780710
Related