The original support for embedded bitcode used appending linkage for the
magic internal variables that hold the bitcode and command line options,
but that private linkage is a better fit. The only real reason for
appending linkage was to prevent those variables from being optimized away.
r269706 limits the use of appending linkage so that it cannot be used for
those variables, so this switches to use private linkage and keep the
variables alive with llvm.compiler.used. This is basically copied from
clang r269679. rdar://problem/28685198.
As of the swift-3.1-branch versions of Clang/LLVM, embedded bitcode is now
working well enough that the tests can be reenabled. rdar://problem/26247134
This should have no functionality change, but is supposed to keep us from
accidentally relying on the "full" Clang importer when in a backend job.
I tested it by archiving a little iOS app from a developer.
Unfortunately, part of the motivation here was that we'd get error messages when
we pass something Clang doesn't like, and that doesn't seem to be happening.
rdar://problem/21389553
Swift SVN r30407
Move helper function EmbedBitcode() from frontend_main.cpp to IRGen.cpp so we
can call it from performIRGeneration when the input file is Swift.
Add testing case to make sure that -embed-bitcode-marker option adds an
empty LLVM bitcode section.
rdar://19048891
Swift SVN r25577
With -embed-bitcode, save a copy of the llvm IR as data in the __LLVM,__bitcode
section and save the command-line options in the __LLVM,__cmdline section.
rdar://19048891
Swift SVN r25560
