This reverts commit r32338 because it appears to have broken Havlak
under the leaks runner, as well as Dictionary and Set on the iOS
simulator.
Swift SVN r32341
can guarantee that the destination has the same or smaller layout.
This is necessary preparation for replacing unsafeBitCast.
It also happens to speedup StrCat by 40%.
Swift SVN r32222
The CaptureInfo computed by Sema now records if the body of the
function uses any generic parameters from the outer context.
SIL type lowering only adds a generic signature if this is the
case, instead of unconditionally.
This might yield a marginal performance improvement in some cases,
but more interestingly will allow @convention(c) conversions from
generic context.
Swift SVN r32161
Move the implementation of SILBasicBlock::splitBasicBlockAndBranch into
CFG's util function swift::splitBasicBlockAndBranch since it's the only
user, and update the latter to take a SILBuilder and use it to create
the branch to the split-off block.
Swift SVN r32128
This analysis provides the following functionality:
1. An abstraction over all loops and basic blocks called a 'region'. For
a given loop this abstraction is used to represent all immediate child
basic blocks (1) and immediate subloops (2) called child regions.
2. Detection of back edges that were not found by SILLoopInfo. The
heads/tails of such back edges are marked as being areas where unhandled
control flow occurs. This enables irreducible control flow to be handled
by users as appropriate.
3. For each loop in the loop tree an RPO/PO ordering of the loop's
subregions. This enables one to run dataflow on the loop tree using loop
abstractions in a structured, clean manner by processing regions and
depending on whether or not the region was a loop/BB handle it
appropriately.
Some notes:
1. Functions are represented as a top level loop.
2. The analysis is setup to conservatively handle loops with the
following properties:
a. Irreducible Control Flow.
b. Multiple Backedges
In these cases, we use the unknown control flow facility to allow for
users of the analysis to handle the behavior appropriately.
We assume 2.b. since I am going to implement canonicalization of
multiple backedge loops into nested loops.
Also two passes are provided for working with this analysis:
1. LoopRegionViewText - Dump loop regions in a textual format. This is
intended for usage with FileCheck tests.
2. LoopRegionViewCFG - Dump loop regions into a CFG pdf. The dumped CFG
includes the loops, functions, and BBs. It represents
successors/predecessors in the loop region by black arrows and
hierarchical relations in between regions/subregions by red dashed
arrows. It also prints out the contents of BBs and whether or not
unknown control flow occurs.
(1) BBs for which this loop is the inner most parent loop.
(2) Loops for which this loop is the inner most parent loop.
Thanks to Arnold review!
rdar://22238531
Swift SVN r32104
Remove the include of SILInstruction.h in a couple places since it is
not necessary and forces more recompilation than necessary when edits
are made to SILInstruction.h.
Swift SVN r32091
Till now, a SIL module would be only verified if an optimization has changed it. But if there were no changes, then no verification would happen and some SIL module format errors would stay unnoticed. This was happening in certain cases when reading a textual SIL module representation, which turned out to be broken, but SIL verifier wouldn't catch it.
Swift SVN r31863
To invoke the front-end on a SIL with whole-module optimizations enabled, execute:
swiftc -frontend myfile.sil
To invoke the front-end on a SIL without whole-module optimizations enabled, add a -primary-file option:
swiftc -frontend -primary-file myfile.sil
To invoke a sil-opt with whole-module optimizations enabled, use the -wmo option:
sil-opt myfile.sil -wmo
This change was need to be able to write SIL unit tests which should be compiled in the WMO mode.
Swift SVN r31862
The two changes were:
1. I added a graphtraits implementation for a const
DomTreeNodeBase<SILBasicBlock>.
2. LoopInfoBase::Analyze() => LoopInfoBase::analyze().
Swift SVN r31807
This re-applies commit r31763 with a change to the predicate we
use for determining the linkage of a definition. It turns out we
could have definitions with a Clang body that were still public,
so instead of checking for a Clang body just check if the Clang
declaration is externally visible or not.
Swift SVN r31777
If an external SIL function has a Clang-generated body, I think this
means we have a static function, and we want to use Shared linkage,
not Public.
Add a new flag to SILFunction for this and plumb it through to
appease assertions from SILVerifier.
Swift SVN r31763
Right now, re-abstraction thunks are set up to convert values
as follows, where L is type lowering:
- OrigToSubst: L(origType, substType) -> L(substType)
- SubstToOrig: L(substType) -> L(origType, substType)
This assumes there's no AST-level type conversion, because
when we visit a type in contravariant position, we flip the
direction of the transform but we're still converting *to*
substType -- which will now equal to the type of the input,
not the type of the expected result!
This caused several problems:
- VTable thunk generation had a bunch of special logic to
compute a substOverrideType, and wrap the thunk result
in an optional, duplicating work done in the transform
- Witness thunk generation similarly had to handle the case
of upcasting to a base class to call the witness, and
casting the result of materializeForSet back to the right
type for properties defined on the base.
Now the materializeForSet cast sequence is a bit longer,
we unpack the returned tuple and do a convert_function
on the function, then pack it again -- before we would
unchecked_ref_cast the tuple, which is technically
incorrect since the tuple is not a ref, but IRGen didn't
seem to care...
To handle the conversions correctly, we add a third AST type
parameter to a transform, named inputType. Now, transforms
perform these conversions:
- OrigToSubst: L(origType, inputType) -> L(substType)
- SubstToOrig: L(inputType) -> L(origType, substType)
When we flip the direction of the transform while visiting
types in contravariant position, we also swap substType with
inputType.
Note that this is similar to how bridging thunks work, for
the same reason -- bridging thunks convert between AST types.
This is mostly just a nice cleanup that fixes some obscure
corner cases for now, but this functionality will be used
in a subsequent patch.
Swift SVN r31486
Also make it more accurate by lowering optional payload types, but
nothing depends on this right now.
Apologies for the recent stream of unrelated-looking NFCs -- the goal
here is to make a big upcoming patch easier to review.
Swift SVN r31480
Previously all uses of this instruction used the single element ArrayRef
constructor. The single element ArrayRef constructor does not require any extra
memory. In the case where one does need extra memory, one would need to allocate
the memory for the init_existential_metatype and pass it in. This commit changes
init_existential_metatype to tail allocate the memory for the conformance
pointers and memcpy them in from the array.
Discovered when a SmallVector of protocol conformances resulted in memory
corruption and frustration =--(.
rdar://22302277
Swift SVN r31276
If the compiler can prove that a throwing function actually does not throw it can
replace a try_apply with an "apply [nothrow]". Such an apply_inst calls a function
with an error result but does not have the overhead of checking for the error case.
Currently this flag is not set, yet.
Swift SVN r31151
dealloc_ref [destructor] is the existing behavior. It expects the
reference count to have reached zero and the isDeallocating bit to
be set.
The new [constructor] variant first drops the initial strong
reference.
This allows DI to properly free uninitialized instances in
constructors. Previously this would fail with an assertion if the
runtime was built with debugging enabled.
Progress on <rdar://problem/21991742>.
Swift SVN r31142
the type-checker. The strategy for now is to just use this
for protocol witness thunk emission, where it is required
when generating a materializeForSet for storage that is
either implemented in a protocol extension or requires
reabstraction to the requirement's pattern.
Eventually, this should be generalized to the point that
we can use it for all materializeForSet emission, which
I don't think will take much. However, that's not really
the sort of instability we want to embrace for the current
release.
WIP towards rdar://21836671; currently disabled, so NFC.
Swift SVN r31072
Often times one will want to process a BuiltinInst just based off of the
intrinsic or builtin kind. Generally one only wants to process one or
the other and has to introduce variables for the IntrinsicInfo or
BuiltinInfo to a wider scope than one wishes to. These builtins simplify
the processing of such builtins by allowing one to create an if
statement scope around the variable.
if (auto Kind = BI->getBuiltinKind()) {
...
}
if (auto ID = BI->getIntrinsicID()) {
...
}
Swift SVN r30835
This patch implements the pre-specialization for the most popular generic types from the standard library. If there are invocations of generic functions from the standard library in the user-code and the compiler can find the specialized, optimized versions of these functions, then calls of generic functions are simply replaced by the calls of the specialized functions.
This feature is supposed to be used with -Onone to produce much faster (e.g. 5x-10x faster) executables in debug builds without impacting the compile time. In fact, the compile-time is even improved, because IRGen has less work to do. The feature can be considered a light-weight version of the -Odebug, because pre-specialization is limited in scope, but does not have a potentially negative compile-time impact compared to -Odebug. It is planned to enable it by default in the future.
This feature is disabled by default for the time being. It can be enabled by using a hidden flag: -Xllvm -use-prespecialized.
The implementation consists of two logical steps:
- When the standard library is being built, we force a creation of specializations for the most popular generic types from the stdlib, e.g. Arrays of integer and floating point types, Range<Int>, etc. The list of specializations is not fixed and can be easily altered by editing the Prespecialized.swift file, which is responsible for forcing the specialization of generic types (this is simple solution for now, until we have a proper annotation to indicate which specializations of a given generic type or function we want to generate by means of the pre-specialization). These specializations are then optimized and preserved in the stdlib dylib and in the Swift SIL module. The size increase of the stdlib due to creation of pre-specializations is currently about 3%-7%.
- When a user-code is being compiled with -Onone, the compiler would run a generic specializer over the user-code. If there are calls of generic functions from the standard library, the specializer would check if there is an existing specialization matching these invocations. If such a specialization is found, the original call is replaced by the call of this more efficient specialized version.
Swift SVN r30309
This feature is required for the implementation of pre-specialization, because one needs to check if a specialized SIL function with a given name exists in the standard library.
Swift SVN r30307
