Bitcode
I managed to ask Chris Lattner this very question at WWDC (during a moment when he wasn’t surrounded by adoring crowds). “So, you’re signaling a new CPU architecture?” But, “No; think more along the lines of ‘adding a new multiply instruction’. By the time you’re in Bitcode, you’re already fairly architecture-specific” says he.
surprised most dev gripes about bitcode is unpredictable optimization effects. Folks, we’ve been living in emulated ISAs since the 90s
I think bitcode is a huge win. About only thing I’ll miss is cool ISA-specific instructions. Now reliant on OS vendor providing access.
I’m a lot less worried about emulated ISAs given that the chances I have to debug one are pretty much nil.
Bitcode: non-reproducible Apple-internal toolchain bugs, emergent bugs from undefined behavior that previously worked, etc ...
When it becomes a requirement to submit apps in bitcode format, how will this impact architecture specific code (ie. assembly, or anything that is ifdef’d for that matter). It makes sense that assembly isn’t converted to bitcode, but doesn’t everything need to be in bitcode in order for an archive to be fully encoded in bitcode? I have an app that’s hitting a compile warning when archiving complaining that a specific 3rd party library doesn’t contain bitcode so the app cannot be archived with bitcode. That 3rd party library won’t emit bitcode ostensibly because it contains assembly (I could be wong about the cause, though).
I suppose this would also allow Swift ABIs to change at any time, without dylibs in the app.
See also Accidental Tech Podcast episodes 122, 123, and 124.
Update (2015-09-25): Alex Denisov:
This picture clearly demonstrates how communication between frontend and backend is done using IR, LLVM has it’s own format, that can be encoded using LLVM bitstream file format - Bitcode.
Just to recall it explicitly - Bitcode is a bitstream representation of LLVM IR.
Bitcode will enable support for better microarchitecture support but gets nowhere close to target independence. Applications compiled for the armv7 target could still run on armv7s devices but additional optimisations make applications faster if they contain a armv7s slice. The advantage that Bitcode provides on top of app thinning is negligible in my opinion since it will only provide a slight speed up until the developer uploads a new build with the optimized slice.
[…]
The centralization of the building and signing process is what worries me: an adversary could find a vulnerability in the LLVM backend to obtain remote code execution on Apple’s Bitcode compilation infrastructure to inject a compiler trojan that would affect every single app on the App Store that was submitted with Bitcode.
