No. It is not that abstract or general. It enables tuning, but several aspects of the target architecture are assumed in the bitcode. It allows for CPU-aware optimization passes, such as - for example - reconfiguring math to use faster instructions when possible, but it is specifically not an abstract machine-independent bytecode.
True, bitcode is not completely abstract, and things like calling conventions are baked into the bitcode.
But it is abstract enough that Apple could use it to recompile binaries for, say, a new 64-bit CPU architecture.
Yes, they might have to jump through a few hoops to make it work, but given the control that Apple have over their platforms (they can define things like calling conventions) it shouldn't be too difficult.
Apple did JIT compilation of binaries during the PowerPC -> Intel transition years ago. Recompiling bitcode on the App Store would be easy by comparison!
Apple's PPC emulation was carried out at the process level. That means that not only the program was PPC, but also all libraries it used. And that means that Apple had to keep shipping PPC versions of all their system frameworks.
When it comes to 32-bit ARM, that's basically the situation Apple is already in. It's just that instead of emulation, the 32-bit code is run natively by the CPU.
They could replace that with an actual emulator, but it would gain you almost nothing. 32-bit support in the CPU doesn't cost much. The real reason Apple wants to dump 32-bit support is so they can stop shipping 32-bit versions of all their system libraries. Doing that will save disk space, memory, and development effort.
It's really, really hard to create an emulator which will run a 32-bit program that talks to 64-bit libraries, and bitcode doesn't help.
I was not suggesting that bitcode could be used for 32-bit -> 64-bit translation, but rather that bitcode means that Apple may be able to avoid similar situations in the future.
In any case, these (32-bit only) binaries predate bitcode by several years, so it's not relevant.
Lattner said that bitcode is "not a panacea that makes everything magically portable"[1], which of course is true.
But that doesn't mean it couldn't be recompiled for different architectures, given reasonable bounds like both 64-bit, same endian, similar calling conventions, etc.
I'm not suggesting Apple is considering that, just that it would be technically possible if there were ever a compelling reason.
It's unlikely they would ever move away from ARM on iOS, but on something like the Apple Watch with it's highly custom SIP, and ultra-low-power requirements, you never know...
He actually references that pretty specifically saying that indeed it can't be used to move 32bit -> 64bit [0]
> 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
