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
Commands like -emit-sil and -emit-module (on its own) do not produce object files.
When -embed-bitcode is also set, the driver runs a backend job to generate a module that fails.
This commit emits a warning instead and ignores the -embed-bitcode option.
https://bugs.swift.org/browse/SR-3352
The "Tool" abstraction wasn't buying us enough to deserve the added
complexity. Now a ToolChain turns Actions into Jobs, and every helper
tool is searched for relative to Swift first. Much simpler.
Swift SVN r31563
Previously we treated this the same as the inputs to the linker, but this
was problematic for a few reasons:
- Backend jobs don't produce
- .o inputs never produce .swiftmodule files (obviously).
So now we:
- explicitly track what can produce a swiftmodule
- don't run module merging if there's nothing to merge
- allow linking without a swiftmodule even under -g
Which gets us closer to being able to run the entire test suite with -g.
rdar://problem/22332569
Swift SVN r31376
This is consistent with Clang, which rejects -mllvm options. All options
Clang /does/ accept should be covered by normal Swift flags.
rdar://problem/21245117
Swift SVN r29386
This already works (and isn't testing much beyond CHECK-MODULE, above),
but it's probably good to have a multi-file non-single-frontend test.
Swift SVN r29078
With both force-single-frontend-invocation and embed-bitcode, we create
CompileJobAction and BackendJobAction, similar to how we handle embed-bitcode
with StandarCompile.
This commit should only affect Bitcode mode.
rdar://20796819
Swift SVN r28129
With both emit-module and embed-bitcode, MergeModule will get the swiftmodule
inputs from CompileJobAction instead of BackendJobAction.
This commit should only affect Bitcode mode since it only touches how we handle
BackendJobAction which is used for Bitcode mode.
rdar://20678489
Swift SVN r27878
With -embed-bitcode, we will invoke swift twice, once to generate the bitcode
file, the second time to perform code generation on the bitcode file.
For now, -embed-bitcode causes -incremental builds to not be incremental,
because of potential issues of mixing the two.
rdar://19048891
Swift SVN r25559
David Ungar
Jordan Rose
Matthew Carroll
Dmitri Gribenko
Manman Ren
Graham Batty