[LeoNatan25]

Bitcode does not allow cross-architectural builds. This is a common misconception. IR (& bitcode) includes architecture and platform-specific ABI. What it does allow is for better optimizations as the LLVM backend optimizer improves.

[pjmlp]

Standard bitcode does not, but there are people at LLVM and Apple working on a portable version of it, if you check LLVM talks.

[caf]

This is potentially a problem, as better optimisers can bring to life previously dormant bugs in the code.

[jevinskie]

I would imagine that with enough engineering effort, a cross-architecture "porting" of IR would be feasible. I doubt Apple will bother to do that when they can just force developers to rebuild and republish lest they get left out of the App Store.

[LeoNatan25]

Outside of a Java-style high-level VM, cross-platform cross-architecture in the C world requires compilation. You cannot use what is not there. When compiling a C language, macros are used to determine architecture and platform, and extra code is simply not compiled. The most simplest of examples is endianness handling, which would be totally broken if Intel-compiled code is automagically made to run on arm.

[astrange]

iOS and macOS are both little-endian, but there are many other differences between platforms (like pointer alignment, SIMD size, ObjC ABI) and bitcode makes no effort at all to accommodate them.

Bitcode can used to recompile for minor ARM updates, compiler bugs, new optimizations etc without having to get developers to submit new binaries.

[pjmlp]

> Outside of a Java-style high-level VM, cross-platform cross-architecture in the C world requires compilation.

Kind of.

On IBM i, C compiles to TIMI bytecode just like everything else. For producing actual native code directly from the compiler you need the Metal C compiler, or the POSIX compatibility environment (PASE).

The TenDRA C and C++ compilers also used bytecode (TenDRA Distribution Format).

http://www.tendra.org/tdf-guide

[sneak]

Ahh, good to know.