Add SymbolObjectCodeRequest, which emits object
code for a specific set of symbols by querying
TBDGen for the source of the symbols, and asking
SILGen (and eventually IRGen) to emit them.
Rename the member on ASTLoweringDescriptor and
IRGenDescriptor to make it more explicit it returns
the files that need emitting, rather than just the
files that happen to be present. This distinction
will become important once we start emitting code
only for a specific set of symbols.
Do not gate the coroutine extension points on the LLVM passes. Without
running this pass, the generated IR cannot be used by the LLVM tooling.
This allows generating the LLVM IR to debug issues in the LLVM backend.
I encountered this when trying to isolate a debug info generation bug
which seems to be caused by the SRoA pass in LLVM. By allowing to emit
the LLVM IR without the LLVM optimizations, it is possible to isolate
the LLVM pass operation via `opt` from LLVM.
With an inverted pipeline, IRGen needs to be able
to compute the linker directives itself, so sink
it down such that it can be computed by the
`IRGenDescriptor`.
Two protocol conformance descriptors are passed to
swift_compareProtocolConformanceDecriptors from generic metadata
accessors when there is a canonical prespecialization and one of the
generic arguments has a protocol requirement.
Previously, the descriptors were incorrectly being passed without
ptrauth processing: one from the witness table in the arguments that are
passed in to the accessor and one known statically.
Here, the descriptor in the witness table is authed using the
ProtocolConformanceDescriptor schema. Then, both descriptors are signed
using the ProtocolConformanceDescriptorsAsArguments schema. Finally, in
the runtime function, the descriptors are authed.
This commit adds -lto flag for frontend to enable LTO at LLVM level.
When -lto=llvm given, compiler emits LLVM bitcode file instead of object
file and adds index summary for LTO.
In addition for ELF format, emit llvm.dependent-libraries section to
embed auto linking information
to match the one specified in LLVM's Mach-O parser.
Otherwise LLDB could not possibly find it!
This name is used by the swift -modulewrap subcommand, which is currently unused
on Darwin, and primarily intended for use under Linux. However, it may be useful
to better support static archives (.a) files with Swift debug info in the
future. To fully support this, dsymutil and LLDB need to know to look for Swift
AST sections in Mach-O objects other than .dSYM bundled.
Implementation note: It would be nice to get the section name out of libObject,
but with the current architecture this needs a major refactoring that didn't
seem justified, given that there is an end-to-end test to prevent such a mishap
in the future.
<rdar://problem/63991514>
This commit adds -lto flag for driver to enable LTO at LLVM level.
When -lto=llvm given, compiler emits LLVM bitcode file instead of object
file and perform thin LTO using libLTO.dylib plugin.
When -lto=llvm-full given, perform full LTO instead of thin LTO.
The Objective-C runtime expects a signed pointer here. The existing test
would have caught this, except it was always disabled because the
symbol name passed to the dlsym() check should not have had the leading
'_'.
Fixes <rdar://problem/57679510>.
Destroying the SIL remark streamer after transferring ownership to LLVM
is frought. For one, the streamer holds the remark file's stream open.
Destroying it early doesn't accomodate sil-opt, which transfers control
to LLVM before running passes that emit remarks.
Instead, just take a reference to the context that the streamer gets
parented onto. If the remarks streamer infrastructure could just hold
the file stream open for us, we wouldn't have to do any of this.
Corrects a mistake introduced in #31106
I was under the impression that the LLVMContext for an instance of
llvm::remarks::RemarkStreamer was somehow just scratch-space. It turns
out the ASMPrinters don't gather remarks data from modules, they gather
it from the remark streamer associated with the module's context.
Thus, we cannot have the module's context be distinct from whatever
context the streamer is eventually associated with.
In order to bring these two systems back into harmony, introduce a simple
ownership contract to SILRemarkStreamer. That is, it starts owned by
a SILModule, in which case the SILRemarkStreamer holds onto the
underlying LLVM object as the optimizer emits remarks. When it comes
time to IRGen the module, then and only then do we install the streamer
on the module's context. This tranfers ownership of the underlying LLVM
streamer to LLVM itself, so it acts as a consuming operation. When we
are about to perform IR Generation, the SILModule will be expiring
anyways, so the streamer was already about to be destroyed.
We're just putting it to better use doing its job.
SynthesizedFileUnits are attached to a SourceFile.
Make IRGen consistent with TBDGen: when processing a SourceFile, only process
the attached SynthesizedFile. This avoids IRGen/TBDGen inconsistencies.
Use SourceFile name in SynthesizedFileUnit::getDiscriminatorForPrivateValue.
Resolves TF-1249.
swift::GeneratedModule encapsulates an llvm::Module, llvm::LLVMContext
pair that must live and die together. It has convenient accessors for
projecting the module and context components. The meat of this type is
the two conversion functions, which transfer ownership of either the
module component to the caller or the module and context to ORCJIT.
This is because ORC enforces an ownership contract that is distinct from
LLVM's rather wild ownership story for modules and their associated
contexts. See http://llvm.org/docs/ORCv2.html#how-to-use-threadsafemodule-and-threadsafecontext
Teach the driver to pass the SDK version it computes (from the SDK
settings JSON in a Darwin-based platform's SDK) down into the frontend.
The frontend then sets that SDK version in the LLVM module, which
eventually makes its way into the Mach-O file.
Last part of rdar://problem/60332732.
Add implicit declarations generated by the differentiation transform to a
`SynthesizedFileUnit` instead of an ad-hoc pre-existing `SourceFile`.
Resolves TF-1232: type reconstruction for AutoDiff-generated declarations.
Previously, type reconstruction failed because retroactively adding declarations
to a `SourceFile` did not update name lookup caches.
`SynthesizedFileUnit` is a container for synthesized declarations. Currently, it
only supports module-level declarations.
It is used by the SIL differentiation transform, which generates implicit struct
and enum declarations.
Without whole module optimization, the metadata accessors are emitted on
a per-file basis. The result is that if the file containing a generic
type is processed before the file containing a usage of that type that
would result in that prespecialization, the metadata accessor would have
already been emitted by the time that the usage is noted, making it
impossible for the newly created prespecialization to be returned from
the already-emitted metadata accessor.
Here, require that either whole module optimization is enabled so that
the metadata accessors are all emitted at once at the end, or else that
the usage of the prespecialization is in the same file as the type is
declared.
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack.
This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator.
Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
