Isn't that rumor solidly debunked by the fact that LLVM bitcode is strictly tied to the cpu architecure and kernel/system ABI which varies quite a bit between arm/arm64/x86/x86_64?
Has anyone been able to execute built-for-x86_64 bitcode on aarch64 ever?
I will say, however, that executing LLVM bitcode on different targets than the compilation machine is a subject of active research. It's one of the things that I work on in my day job.
Bitcode is not [12:30] a magic solution, though. You can't take a 32-bit app, for example, and run it on a 64-bit device. That kind of portability isn’t something that Bitcode can give you, notably because that is something that's visible in C. As you're writing C code, you can write #ifdef pointer size equals 32, and that’s something that Bitcode can't abstract over. It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything [13:00] magically portable.
What’s funny, is later on after Apple shipped a 64 bit chip for the Apple Watch. He admitted that forcing developers to ship watch apps as bitcode allowed Apple to recompile all of the third party Watch apps on the fly to support it, he knew that was coming, but couldn’t say anything at the time.
The bitcode requirement was driven by the Apple Watch launching with a 32-bit ARM core, but Apple knowing they would move to AArch64 3 years later and not wanting to make devs recompile their apps (or have to support both ISAs on the Watch). The ABIs were designed to be compatible, and apps in the store were statically recompiled to AArch64 for the S4 launch last year.
Has anyone been able to execute built-for-x86_64 bitcode on aarch64 ever?