This disables inlining at the SIL level. LLVM inlining is still enabled. We can
use this to expose one function at the SIL level - which can participate in
dominance based optimizations but which is implemented in terms of a cheap check
and an expensive check (function call) that benefits from LLVM's inlining.
Example:
The inline(late) in the example below prevents inlining of the two checks. We
can now perform dominance based optimizations on isClassOrObjExistential.
Without blocking inlining the optimizations would apply to the sizeof check
only and we would have multiple expensive function calls.
@inline(late)
func isClassOrObjExistential(t: Type) -> Bool{
return sizeof(t) == sizeof(AnyObject) &&
swift_isClassOrObjExistential(t)
}
We do want inlining of this function to happen at the LLVM level because the
first check is constant folded away - IRGen replaces sizeof by constants.
rdar://17961249
Swift SVN r21286
Now that the ARC optimizer does not rely on stripCasts I also added
unchecked_trivial_bit_cast to stripCasts.
This and r21164 give the following speedups > 10%:
Ary 55.95%
MatMul 36.71%
Ary2 34.97%
Richard 32.08%
PrimeNum 15.87%
<rdar://problem/17456455>
Swift SVN r21240
This is the current behavior for @semantics("readonly") and it is needed by the high-level
optimization passes because after inlining the semantics/effects information is lost.
Swift SVN r21084
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
Fixes part of <rdar://problem/16196801>.
Inline generic functions, but only when:
- There are no unbound archetypes being substituted (due to various
assumptions in TypeSubstCloner about having all concrete types).
- When no substitution is an existential (due to
<rdar://problem/17431105>, <rdar://problem/17544901>, and
<rdar://problem/17714025>).
This gets things limping along, but we really need to fix the above
limitations so that mandatory inlining never fails.
This doesn't enable inlining generics in the performance inliner. There
is no reason it shouldn't work as well, but there is no compelling
reason to do so now and it could have unintended effects on performance.
Some highlights from PreCommitBench -
O0:
old (ms) new (ms) delta (ms) speedup
ForLoops 1127.00 294.00 833.00 283.3%
LinkedList 828.00 165.00 663.00 401.8%
R17315246 982.00 288.00 694.00 241.0%
SmallPT 3018.00 1388.00 1630.00 117.4%
StringWalk 1276.00 89.00 1187.00 1333.7%
-- most others improve ~10% --
O3:
old (ms) new (ms) delta (ms) speedup
Ackermann 4138.00 3724.00 414.00 11.1%
Life 59.00 64.00 5.00 -7.8%
Phonebook 2103.00 1815.00 288.00 15.9%
R17315246 430.00 582.00 152.00 -26.1%
StringWalk 1173.00 1097.00 76.00 6.9%
Ofast:
old (ms) new (ms) delta (ms) speedup
Ackermann 3505.00 3715.00 210.00 -5.7%
Life 49.00 41.00 8.00 19.5%
Memset 684.00 554.00 130.00 23.5%
Phonebook 2166.00 1769.00 397.00 22.4%
StringWalk 829.00 790.00 39.00 4.9%
I've opened the following to track remaining issues that need to be
fixed before we can inline all transparent function applications:
<rdar://problem/17431105>
<rdar://problem/17544901>
<rdar://problem/17714025>
<rdar://problem/17768777>
<rdar://problem/17768931>
<rdar://problem/17769717>
Swift SVN r20378
*NOTE* This linkage is different from {Public,Hidden}External in that it has no
extra semantic meaning beyond shared.
The use of this linkage is to ensure that we do not serialize deserialized
shared functions. Those shared functions can always be re-deserialized from the
original module. This prevents a whole class of bugs related to the
creation of module cross references since all references to the shared
item go straight to the original module.
<rdar://problem/17772847>
Swift SVN r20375
We ignore casts when generating projection paths for alias analysis. When
comparing two paths, we say no alias when accessing different fields of
the same Decl Context.
Swift SVN r20353
introduced, as these are obvious miscompilations and clearly mystifying to our user base.
This is enough to emit diagnostics like this:
writeback_conflict_diagnostics.swift:58:70: error: inout writeback aliasing conflict detected on computed property 'c_local_struct_property'
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
writeback_conflict_diagnostics.swift:58:33: note: concurrent writeback occurred here
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
which isn't great, but is better than nothing (better wording is totally welcome!).
This doesn't handle subscripts (or many other kinds of logical lvalue) at all yet, so
it doesn't handle the swift WTF case, but this is progress towards that.
Swift SVN r20297
Structs and enums may recursively refer to themselves in function types and metatypes, which don't actually affect the layout of the type. We don't need to fully lower the storage types of a struct or enum to lower the type; all we need to know is its classification. We can lazily lower the fields, avoiding reentry. Fixes a few dozen radars.
Swift SVN r19968
This commit enables support in the optimizer for promoting the following
unchecked_addr_cast kinds to object bit casts:
1. (Trivial => Trivial) yields a trivial bit cast.
2. (Non-Trivial => Trivial) yields a trivial bit cast.
3. (Non-Trivial => Non-Trivial) yields a ref bit cast.
We do not promote conversions in between trivial and non-trivial types
since a trivial bit cast must have a trivial output and if we allowed
for ref bit casts in between the two, we would be breaking the rule that
ref bit casts do not change the reference semantics of its input, output
types. Technically, we could lower trivial => trivial as a ref cast and
then simplify later but that is unnecessary currently.
<rdar://problem/17373087>
Swift SVN r19784
SIL SROA needs to know when a struct's visible fields actually completely make up the struct value, which becomes an issue if we start importing structs with yet-unrepresentable unions and bitfields. Track this in the ClangImporter, and add an 'aggregateHasUnreferenceableStorage' predicate to SILType to make it easy for passes to query. Part of <rdar://problem/17555966>.
Swift SVN r19720
Fixes <rdar://problem/17579272> SILCombine assert: ty->isLegalSILType() constructing SILType with type that should have been eliminated by SIL lowering.
Fix suggested by MikeG.
Swift SVN r19701
This is using LLVM's SSAUpdater utility.
I had to abstract it a little further because our 'phi' nodes are slightly
different. The SSAUpdater needs to iterate over phis in a basic block so I
abstracted this in a trait. Therefore, this commit needs a recent version of
puzzle/master which has this change applied.
Swift SVN r19634
AST context substitution may produce a metatype, function type, or other type that requires lowering. Handle this special case to fix a crash when emitting protocol conformances with metatypes or functions as associated types. <rdar://problem/17501507>
Swift SVN r19580
Enable SIL parsing and SIL serialization of semantics.
We add one more field to SILFunctionLayout for semantics. We should refactor
handling of attributes at SIL level, right now they are in SILFunction as bool
or std::string and in SIL serializer as a 1-bit field or an ID field.
rdar://17525564
Swift SVN r19434
In a few places we were calling into a function that just returned
T->hasArchetype(). This just changes those places to test it directly.
Swift SVN r19427
This is tested by an assertion in IRGen. After Beta3, this code is going
to go away and be replaced by just always promoting the cast. Then the
IRGen assertion will be replaced by propagating undef. The assertion in
the stdlib will still fire in that case since the assertion is based on
the tops not the given value implying that we will not lose any
correctness.
Swift SVN r19272
These instructions do a bitcast operation without stack traffic (at the SIL level). unchecked_trivial_bit_cast represents a conversion from a potentially nontrivial type to a trivial type, such as from a class reference to Int. unchecked_ref_bit_cast represents a conversion between types for which retain_value and release_value has equivalent effects when applied on the input or output values.
Swift SVN r19053
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 SILModule.
This is useful when coercion to the most general
abstraction is necessary (for example, to establish
consistency in dynamic casts). Often there's an
unbounded archetype at hand, but not always.
Swift SVN r19042
