This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
This patch contains an initial implementation of CSE for SIL ported from LLVM's
earlycse pass. It follows the overall general structure using
ScopedHashTables/DominatorTrees to perform the computation.
Currently it only handles integer literals to ease with the initial review. Once
this gets in I will be spending some time extending the pass to handle other
instructions.
Even with just handling integers this reduces the size of the stdlib in SIL by
~300 lines.
Swift SVN r10794
If given a SourceFile, only decls within that SourceFile will be serialized.
Decls within other SourceFiles are emitted using cross-references that refer
to the current module.
Known issues:
- External definitions won't be serialized by any source file. They probably
have to be serialized into /all/ of them.
- Nothing can actually /read/ a serialized partial-module yet. We need a
notion of a TranslationUnit that can contain both source and serialized
files, and we probably need loading to be more lazy.
Swift SVN r9978
dead blocks (which happens to be incorrect).
Unlike the LLVM SimplifyCFG pass, this one will be worklist-based instead of
iterative, avoiding needless iteration over the entire function when a small
local changes are being made.
Swift SVN r9756
clean up a couple random things in silcombiner:
- it shouldn't return "made any changes" out of the pass.
- statistics should be spelled out more and don't end with periods.
Swift SVN r9755
This pass is a port of InstCombine from LLVM to SIL. Thus if you are familiar
with the code from InstCombine you will feel right at home.
Keep in mind that in order to help with review, this is just a skeleton with no
optimizations in it besides a simple DCE based off of isInstructionTriviallyDead
(which this patch exposes in Local.h like LLVM does) to ensure that trivial
testing of the pass can be accomplished since otherwise it would do nothing
implying that no tests could be written at all.
I additionally modified one test which no longer passed due to SILCombine
removing 1x unused metatype instruction from the standard library.
Swift SVN r9404
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
Once we have multiple SourceFiles in a TranslationUnit, it no longer makes
sense to say "only SILGen decls starting from element N" without specifying
which source file you mean.
Also, clarify ownership by having performSILGeneration return a unique_ptr
instead of just a bare pointer.
Swift SVN r9112
Now that TypeChecker is being used to check all sorts of things (not all
from a single TU), it's not really correct to have a single top-level TU
that gets used everywhere. Instead, we should be using the TU that's
appropriate for whatever's being checked. This is a small correctness win
for order-independent type-checking, but is critical for multi-file
translation units, which is needed for implicit visibility.
This basically involves passing around DeclContexts much more.
Caveat: we aren't smart about, say, filtering extensions based on the
current context, so we're still not 100% correct here.
Swift SVN r9006
- Introduces the Builtin
- If the first parameter evaluates to '1', the dataflow diagnostics pass produces a diagnostic.
- The Builtin gets cleaned up before IRGen, but not before SIL serialization.
This patch also removes the current, overflow warning and XFAILs one of the tests. The other test is switched to use Builtin.staticReport.
TODO:
- Utilize the other parameters to the builtin - the Message and IsError flag.
- Use this Builtin within the stdlib.
Swift SVN r8939
pass to be -definite-init instead of -memory-promotion, rename the
entrypoint for the pass to match, and tidy various and sundry comments.
Swift SVN r8927
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
SerializedSILLoader to hold a list of SIL deserializers.
Also add an intial implementation of a linking pass that is run right after
SILGen to link the declaration of SILFunction to the actual definition in
the serialized module.
We add two blocks to the serialized module: a sil index block that
maps identifier to a function ID and also holds a list of function offsets,
and a sil block for the actual SILFunctions. We can probably use subblock
instead of two top-level blocks.
The serialization/de-serialization of the function hash table and the function
offsets are implemented. But we are missing handling of types (see FIXME in
the code).
ModuleFile::Serialized is made public to be used by SIL deserializer, as well
as ModuleFile::getType.
The SIL deserializer holds a pointer to the ModuleFile, it gets the sil cursor
and the sil index cursor from the ModuleFile. The other option is for SIL
deserializer to find the start of the two sil blocks within itself, thus having
less coupling with ModuleFile.
No testing case yet because we are missing handling of types.
Swift SVN r8206
Fixes two bugs in Clang importer and deserialization code that were found by
the verifier:
(1) FuncExprs were created with a null FuncDecl
(2) BoundGenericType that was created by Clang importer for UnsafePtr<> and
other magic types did not have substitutions.
Swift SVN r8073
Add SerializeSIL.cpp for basic implementation of a SIL serializer.
serialize, serializeToStream, Serializer::writeToStream, and
Serializer::writeTranslationUnit all take an additional SILModule to pass it
to Serializer::writeSILFunctions.
Serializer::writeSILFunctions goes through all SILFunctions in a SILModule, and
serializes all SILFunctions that are transparent.
Swift SVN r7875
In Swift, a module is expected to know which libraries it needs, rather than
having this specified by an external module map. While we haven't quite
designed this yet (frameworks get this for free in Clang, for example),
we can at least provide a simple option for the common case of a module
associated with a single library.
This will probably change in the future, so I left in the more general
deserialization code I was working on before simplifying the use case.
A loaded module can in theory specify any arbitrary frameworks or libraries
as dependencies, not just a single dylib.
Swift SVN r7583
proposal.
When compiling with debug info, build a swiftmodule that contains all the
type decls referenced by DWARF and emit it into a special __apple_swiftast
section in the .o file.
Swift SVN r7398
This introduces the required code completion callbacks which pass partially
parsed TypeReprs to code completion. These types can refer to generic function
parameters. Because we need to typecheck these types, we need to typecheck
generic parameters first. Because exposing fine-grained typechecker interface
just for code completion is bad, we create a function declaration based on the
limited information we have (i.e., just the function name and generic
parameters) and pass that to the typechecker. This approach (in theory) should
work uniformly for function decls and nominal type decls, but the nominal type
decl case is not tested yet. Eventually we will also want to use a similar
approach for normal parser recovery as well.
Swift SVN r7313
definite initialization, promoting boxes to stack, building ssa, and doing definite
initialization.
I'll build this in place, then kill off the other two passes when this subsumes them.
Swift SVN r6903
around everywhere
Fixes:
rdar://14585108 Code completion does not work at the beginning of the file
rdar://14592634 Code completion returns zero results at EOF in a function
without a closing brace
Swift SVN r6820
DCE is added as a separate SIL pass with it's own entry point.
For now, detect and simplify the branch instructions with constant
conditions and delete unreachable basic blocks (for now, we do not even
pay any regards to the basic block arguments).
Swift SVN r6713
fix the build. This isn't a proper fix (we should start putting out new attributes
on llvm::Function's, but getting the build working again seems important.
Swift SVN r6584
-Introduce PersistentParserState to represent state persistent among multiple parsing passes.
The advantage is that PersistentParserState is independent of a particular Parser or Lexer object.
-Use PersistentParserState to keep information about delayed function body parsing and eliminate parser-specific
state from the AST (ParserTokenRange).
-Introduce DelayedParsingCallbacks to abstract out of the parser the logic about which functions should be delayed
or skipped.
Many thanks to Dmitri for his valuable feedback!
Swift SVN r6580
