Follow up to https://reviews.llvm.org/D64931 to allow existing IR with the old datalayout to compile.
Is that suggestion to handle it in AutoUpgrade.cpp? My rationale for doing it this way was, if a module lacks these address spaces in data layout, it is old bitcode, and it won't use these address spaces for this purpose. But of course, it's unchecked.
This seems to have been causing problems during linking, got hundreds of those:
ld.lld: warning: Linking two modules of different data layouts: '/b/llvm-10/407/lib/libc++.a(cxa_exception.cpp.o at 5739456)' is 'e-m:e-i64:64-f80:128-n8:16:32:64-S128' whereas 'obj/gpr/third_party/protobuf/libprotoc_lib.a(libprotoc_lib.java_message_builder_lite.o at 10565644)' is 'e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128'
If this is only being used for clang-cl (or -fms-compatibility) mode only, is it possible to limit it to just that rather than it affecting pretty much everything?
We decided we'd rather not do that. There needs to be some way to upgrade the x86 datalayout. It can't be frozen in stone forever.
Of course, we need to support the use case of linking old bitcode with new bitcode. Doing that probably requires adding an autoupgrade to replace the old data layout with the new one when loading bitcode. We already have x86-specific intrinsic upgrades in llvm/lib/IR/AutoUpgrade.cpp, so it seems reasonable to add this there, even though it is x86 specific, and remove the X86TargetMachine change.