At some point, pass definitions were heavily macro-ized. Pass
descriptive names were added in two places. This is not only redundant
but a source of confusion. You could waste a lot of time grepping for
the wrong string. I removed all the getName() overrides which, at
around 90 passes, was a fairly significant amount of code bloat.
Any pass that we want to be able to invoke by name from a tool
(sil-opt) or pipeline plan *should* have unique type name, enum value,
commend-line string, and name string. I removed a comment about the
various inliner passes that contradicted that.
Side note: We should be consistent with the policy that a pass is
identified by its type. We have a couple passes, LICM and CSE, which
currently violate that convention.
Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
Swift uses rt_swift_* functions to call the Swift runtime without using dyld's stubs. These functions are renamed to swift_rt_* to reduce namespace pollution.
rdar://28706212
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
This prevents the linker from trying to emit relative relocations to locally-defined public symbols into dynamic libraries, which gives ld.so heartache.
And include some supplementary mangling changes:
- Give the first generic param (depth=0, index=0) a single character mangling. Even after removing the self type from method declaration types, 'Self' still shows up very frequently in protocol requirement signatures.
- Fix the mangling of generic parameter counts to elide the count when there's only one parameter at the starting depth of the mangling.
Together these carve another 154KB out of a debug standard library. There's some awkwardness in demangled strings that I'll clean up in subsequent commits; since decl types now only mangle the number of generic params at their own depth, it's context-dependent what depths those represent, which we get wrong now. Currying markers are also wrong, but since free function currying is going away, we can mangle the partial application thunks in different ways.
Swift SVN r32896
We can't bitcast an i64 into an i8*, we have to do an int to pointer
cast instead.
This exposes a new issue, where dynamic casts do not support casting
from Optional<A> to A -- tracked in <rdar://problem/23122310>.
Fixes <rdar://problem/23055035>.
Swift SVN r32704
This improves support for promoting to and generating
unchecked_ref_cast so we no longer need unchecked_ref_bit_cast, which
will just go away in the next commit.
Swift SVN r32597
These classes don't show up well in generated headers (rdar://problem/20855568),
can't actually be allocated from Objective-C (rdar://problem/17184317), and
make the story of "what is exposed to Objective-C" more complicated. Better
to just disallow them.
All classes are still "id-compatible" in that they can be converted to
AnyObject and passed to Objective-C, they secretly implement NSObjectProtocol
(via our SwiftObject root class), and their members can still be individually
exposed to Objective-C.
The frontend flag -disable-objc-attr-requires-foundation-module will disable
this requirement as well, which is still necessary for both the standard
library and a variety of tests I didn't feel like transforming.
Swift SVN r29760
@inout parameters can be nocapture and dereferenceable. @in, @in_guaranteed, and indirected @direct parameters can be noalias, nocapture, and dereferenceable.
Swift SVN r29353
emitScalarExistentialDowncast() would return an explosion consisting
of the original input value, followed by witness tables returned by
calling emitExistentialScalarCastFn().
The result of this explosion was then tested by comparing the first
element against NULL, which is wrong, since the first element was
set to the input value unconditionally.
Address this by changing the dynamic cast functions to take the value
as the first argument, and return it as the first element of the
return tuple. The value is not used directly, only set to NULL if the
cast fails. This makes the NULL check in visitCheckedCastBranchInst()
work as intended.
Note that now the result of the cast becomes a different LLVM value
than the input. With the dynamic cast function inlined, this should
not be an issue, since this is already the case for dynamic class cast.
There are also perhaps too many bitcast instructions generated now.
This could be cleaned up.
Fixes <rdar://problem/20920874>.
Swift SVN r28712
All llvm::Functions created during IRGen will have target-cpu and target-features
attributes if they are non-null.
Update testing cases to expect the attribute in function definition.
Add testing case function-target-features.swift to verify target-cpu and
target-features.
rdar://20772331
Swift SVN r28186
... with disabled test 1_stdlib/Bit.swift for ios.
Most likely the problem of 1_stdlib/Bit.swift (only on armv7) is just uncovered by this change.
Unfortunately I have no possibility to debug the problem on a device. Therefore I filed rdar://problem/20521110
Swift SVN r27274
This avoids that an unoptimized imported function is linked instead the optimized version from the stdlib.
rdar://problem/20485253
It gives considerable performance improvmenets for some benchmarks with -Onone. E.g.
PopFrontUnsafePointer: +281%
ArrayOfPOD: +92%
StrComplexWalk: +91%
ArrayOfGenericPOD: +61%
Several others are within the range of +10% to +30%.
For the implementation I added runSILPassesForOnone() in Passes.cpp.
Here we can add other optimizations for -Onone in the future.
Swift SVN r27206
We have to guarantee memory safety in the presence of the user violating the
inout assumption. Claiming NoAlias for parameters that might alias is not
memory safe because LLVM will optimize based on that assumption.
Unfortunately, this means that llvm can't optimize arrays as aggressively. For
example, the load of array->buffer won't get hoisted out of loops (this is the
Sim2DArray regression below).
-O numbers (before/after):
CaptureProp 0.888365
Chars 1.09143
ImageProc 0.917197
InsertionSort 0.895204
JSONHelperDeserialize 0.909717
NSDictionaryCastToSwift 0.923466
Sim2DArray 0.76296
SwiftStructuresBubbleSort 0.897483
Continue emitting noalias for inout when compiling Ounchecked.
rdar://20041458
Swift SVN r25770
Specialization can introduce 'A as! B' casts between unrelated types A and B, and we're not always smart enough to fold them away to a failure. We shouldn't crash in IRGen when we see them. Fixes rdar://problem/19544667.
Swift SVN r24971
They don't need one, and nobody really conforms to the AnyObject sham protocol at runtime. Fixes rdar://problem/19624697, though there's going to be a similiar problem with metatype-to-AnyObject casts that needs fixing as well.
Swift SVN r24802
We still preserve IRGen's current ordering of vtable slots, but use SIL's record of which SILFunction implements which method instead of walking overrides independently. Another step on the way to rdar://problem/19321484; if SILGen determines that a thunk is needed to interface an override with its base method, IRGen will now pick it up. (Thunk generation is still busted in certain inheritance cases I need to fix before declaring victory though.)
Swift SVN r24732
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
The optimizer could eliminate these but isn't there yet. These instructions are valid nonetheless and should be emittable. Fixes rdar://problem/18934125.
Swift SVN r23269
These always fail, and it doesn't make sense to inline this check into the cast site, so provide additional runtime functions for metatype-to-objc-existential casts.
Swift SVN r23237
The code path here is mostly the same as the class cast case--we have to test the ObjC class (if it is a class) against any ObjC protocols, then look up conformances for the native protocols.
Swift SVN r23184
And in IRGen, fix up pointer cast codegen to work with types that explode to single scalars while being stored in named structs. Fixes rdar://problem/18604262
Swift SVN r22671
Any single-refcounted-pointer type can be cast from a raw pointer. Also generalize unchecked_ref_cast to cast among arbitrary single-refcounted-pointer types. Fixes rdar://problem/18184883.
Swift SVN r21609
It should definitely work with AnyObject, but it can also apply to any class existential by just shedding the witness tables. This lets us eliminate a bunch of unsafeBitCasts from the alimentary canals of the stdlib.
Swift SVN r21472
