There are a handful of places where the result type of an instruction (or ConstantExpr) can depend on one of the input operands during bitcode parsing. We are and have been removing this from bitcode generated in the future, but will still need to be able to read and upgrade old bitcode when we move to opaque pointers.
The high-level effect of this is that BitcodeReader will need to derive the needed type information more or less directly from the type records (which will still contain the full structure of pointer types for old bitcode) rather than from some particular Value's Type, which may be dramatically flattened.
The future I imagine has a BitcodeSerializationPointerType which is only ever created by BitcodeReader.cpp, and then the flattenPointerTypes would recursively convert any given type to use the PointerType on demand, and that's what would end up in Value instances. But there are other ways to do it that don't fundamentally change the structure of this patch as far as I can tell.
I tested the libLTO.dylib with these changes when self-hosting with a clang binary back to 3.6 (before the load/GEP changes) and it works fine. Before that Clang's front-end chokes on something and segfaults; probably something too new in a system header but I didn't investigate.