This commit changes how inline information is stored in SILDebugScope
from a tree to a linear chain of inlined call sites (similar to what
LLVM is using). This makes creating inlined SILDebugScopes slightly
more expensive, but makes lowering SILDebugScopes into LLVM metadata
much faster because entire inlined-at chains can now be cached. This
means that SIL is no longer preserve the inlining history (i.e., ((a
was inlined into b) was inlined into c) is represented the same as (a
was inlined into (b was inlined into c)), but this information was not
used by anyone.
On my late 2012 i7 iMac, this saves about 4 seconds when compiling the
RelWithDebInfo x86_64 swift standard library — or 40% of IRGen time.
rdar://problem/28311051
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
This is the first verifier for SemanticSIL. The verifier is very simple and
verifies that given a SILValue V, V->getOwnershipKind() returns an ownership
kind compatible with all of V's user instructions.
This is implemented by adding a new method to SILInstruction:
SILInstruction::verifyOperandOwnership()
This method creates an instance of the visitor OwnershipCompatibilityUseChecker
and then has the instance visit this.
The OwnershipCompatibilityUseChecker is a SILInstructionVisitor that for a given
instruction verifies that the given SILInstruction's operand SILValue's produce
ValueOwnershipKind that are compatible with the SILInstruction. The reason why
it is implemented as a visitor is to ensure that a warning is produced if a new
instruction is added and a method on the OwnershipCompatibleUseChecker isn't
added.
Keep in mind that this is just the first verifier and the full verifier (that
also verifies dataflow) is built on top of it. The reason why this separate API
to the use verifier is exposed is that exposing the checker enables us to place
an assert in SILBuilder to diagnose any places where SIL ownership is violated
immediately when the violation occurs allowing for an easy debugging experience
for compiler writers. This assert is a key tool that I am going to be using to
make SILGen conform to the SIL Ownership Model.
Again, this will be behind the -enable-semantic-sil flag, so normal development
will be unaffected by this change.
rdar://29671437
Trying to contain it in SIL doesn't really work if we want to be able to print or parse SIL box types, since the type parser and printer doesn't otherwise depend on the SIL module.
This gives us a concept we can eventually use to cache the lowered physical layout of fragile structs and classes, and more immediately, concretize the layout of closure boxes in a way that lets us represent the capture of generic environments and multiple captured values without compromising the "nominal" nature of box layouts. To start exercising the basic implementation, change the representation of SILBoxType to be in terms of a SILLayout, though avoid any immediate functionality change by preserving the single-boxed-type interface for now.
Fix a CMake warning:
```
CMake Warning (dev) in lib/SIL/CMakeLists.txt:
A logical block opening on the line
swift/lib/SIL/CMakeLists.txt:43 (if)
closes on the line
swift/lib/SIL/CMakeLists.txt:46 (endif)
with mis-matching arguments.
This warning is for project developers. Use -Wno-dev to suppress it.
```
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
This will be used to help IRGen record protocol requirements
with resilient default implementations in protocol metadata.
To enable testing before all the Sema support is in place, this
patch adds SIL parser, printer and verifier support for default
witness tables.
For now, SILGen emits empty default witness tables for protocol
declarations in resilient modules, and IRGen ignores them when
emitting protocol metadata.
SILValue.h/.cpp just defines the SIL base classes. Referring to specific instructions is a (small) kind of layering violation.
Also I want to keep SILValue small so that it is really just a type alias of ValueBase*.
NFC.
to represent the accessed fields of the variables in the program. we plan to use Location in
the load forwarding pass as well for similar purposes.
Swift SVN r32427
This is necessary for correctly dealing with non-standard
ownership conventions in secondary positions, and it should
also help with non-injective type imports (like BOOL/_Bool).
But right now we aren't doing much with it.
Swift SVN r26954
This is only used by SILModule but is not integral to a SILModule so it makes
sense to have it in its own file. It keeps SILModule.cpp more focused. We still
keep it in a private header though since it is only meant to be used by
SILModule.cpp.
Swift SVN r25985
This is apart of creating the infrastructure for creating special manglings for
all of the passes that we specialize. The main motiviations for this
infrastructure is:
1. Create an easy method with examples on how to create these manglings.
2. Support multiple specializations. This is important once we allow for partial
specialization and can already occur if we perform function signature
optimizations on specialized functions.
The overall scheme is as follows:
_TTS<MANGLINGINFO>__<FUNCNAME>
Thus if we specialize twice, the first specialization will just be treated as
the function name for the second specialization.
<MANGLINGINFO> is defined as:
_<SPECIALIZATIONKINDID>_<SPECIALIZATIONUNIQUEINFO>
Where specialization kind is an enum that specifies the specific sort of
specialization we are performing and specialization unique info is enough
information to ensure that the identity of the function is appropriately
preserved.
Swift SVN r23801
SILMetadata is the base class with a single enum member (MDKind).
SILBranchNode is the derived class with additional members:
unsigned NumOperands
an array of uint32_t
A static member function SILBranchNode::get is implemented to get or create
SILBranchNode. All SILMetadata created are uniqued and saved in SILModule's
member variable:
llvm::FoldingSet<SILMetadata> Metadatas
Usage of SILMetadta by SILInstruction is captured in SILModule's member variable:
llvm::DenseMap<const SILInstruction *, SILMetadata *> MetadataStore
This is similar to LLVM's Metadata. Another option is to add a SILMetadata* to
SILInstruction. The disadvantage is the waste of space when we don't have PGO on.
This commit also enables parsing and printing of SILMetadata.
We add keyword sil_metadata to define SILMetadata:
sil_metadata !0 = {"branch_weights", 3, 5}
For parsing, we add a map in SILModule
llvm::DenseMap<unsigned, SILMetadata *> NumberedMetadata
that maps from ID to SILMetadata* to help matching usage of "!id" in SILFunction
with definition of "!id" in sil_metadata section.
For printing, we assign IDs to SILMetadata at SILModule scope, we then pass in
an optional argument of
llvm::DenseMap<const SILMetadata *, unsigned> *MetadataMap
to SILFunction::print in order to get the ID of SILMetadata used in
SILInstruction.
Post-commit review will be appreciated.
rdar://18269754
Swift SVN r23713
This follows the model of dominance info and allows me to create reachability
methods on SILBasicBlock without creating dependencies from swiftSIL to
swiftSILAnalysis.
Swift SVN r21866
SILArgument::getIncomingValues() takes in an out array parameter and attempts to
gather up all values from the SILArguments parents predecessors whose value the
SILArgument could take on.
This will let me refactor the single predecessor handling code to also handle
multiple predecessors in a simple way.
Swift SVN r21864
unconditional_dynamic_cast_addr instruction.
Also, fix some major semantic problems with the
existing specialization of unconditional dynamic
casts by handling optional types and being much
more conservative about deciding that a cast is
infeasible.
This commit regresses specialization slightly by
failing to turn indirect dynamic casts into scalar
ones when possible; we can fix that easily enough
in a follow-up.
Swift SVN r19044
- the type of a const global variable
- the type of a parameter, always
- the return type of a function that has been audited
or has an explicit retained/not-retained attribute
- the return type of an ObjC method that has an explicit
retain/not-retained/inner-pointer attribute
Additionally, choose the correct conventions for all
these cases during SIL type lowering.
All this importing logic is still only enabled under
-Xfrontend -import-cf-types.
Swift SVN r17543
Currently SILType's method definitions are strewn in various files in
lib/SIL/*.cpp. This patch just adds a new file SILType.cpp that centralizes
many of those definitions.
*NOTE* Any method which uses declarations inside of a specific *.cpp file I left
alone (there were 3). If we want to, we can perhaps create a new header to share
the interface in between the two. I wanted this change to be as incremental as
possible so I left that undone.
Swift SVN r11890
