Also, dump the module map paths when `-Xfrontend -dump-clang-diagnostics` is
passed in, both so we can check that manually and in these tests, and fix
another Frontend test to be more specific now that this other output trips it up.
Don't run the objc-arc-contract pass when disable-llvm-optzns is passed.
In pipeline setups where the swift-frontend is called twice;
- the first time to create bitcode
- the second time to generate object code from the bitcode (using
disable-llvm-optzns)
we don't want to run the objc-arc-contract pass twice.
rdar://91908312
passes
The test case looks for the Objective C ARC contraction pass. It uses
-Xllvm -time-passes and then greps for the pass. It seems that
-time-passes is not always printing the pass. Use -Xllvm
-debug-pass=Structure instead that should print the added passes
reliably.
rdar://35796399
Otherwise, we leave optimization opportunities on the table, and in
some cases even fail to remove marker intrinsics inserted by earlier
optimization.
Background: under -embed-bitcode, compilation happens in two stages: a
"frontend" job that compiles Swift code, generates LLVM IR, optimizes
it, and then emits a .bc file; and a "backend" job that takes that
.bc, converts it to assembly, and emits an object file with the
original bitcode embedded. However, there are actually optimization
passes that run before and during that "convert to assembly" step that
were getting completely skipped.
rdar://problem/34864094
Avoids a bogus "argument unused" warning, since bitcode compilation
doesn't bother to set up much of a Clang AST context. (-embed-bitcode
compiles in two steps: source -> bitcode, then bitcode -> object
file. This is about the second step.)
Patch by Bob Wilson, who's currently on vacation but wanted this to
get in sooner rather than later.
rdar://problem/31372950
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
