Also handles mangling, demangling, printing and parsing.
This is the first patch to use global getter for "let" globals.
rdar://16614767
Swift SVN r23106
If vtable or witness methods are never called, e.g. because they are completely devirtualized,
then they are removed from the tables and eliminated.
Another improvement of the new algorithm is that it is able to eliminate dead function cycles
(e.g. A() calls B() and vice versa).
Swift SVN r22969
This will let the performance inliner inline a function even if the costs are too high.
This attribute is only a hint to the inliner.
If the inliner has other good reasons not to inline a function,
it will ignore this attribute. For example if it is a recursive function (which is
currently not supported by the inliner).
Note that setting the inline threshold to 0 does disable performance inlining at all and in
this case also the @inline(__always) has no effect.
Swift SVN r21452
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
Make ObjC method partial applications go through a native-to-foreign thunk so that we properly handle bridging conversions in the resulting function value. Partial applications through dynamic lookup are still broken because they apparently go through a different path.
Swift SVN r17108
inherited conformances can result in virtual calls to overriding
subclass methods.
Previously given the following swift code:
protocol P {
func x()
}
class B : P {
func x() { ... }
}
class B2 : B {
func x() { ... }
}
func doX<T : P>(t : T) {
t.x()
}
var b2 = B2()
doX(b2)
We would have b2 reference the protocol method for B.x. But since the
protocol method B.x would have a direct function reference to B.x, we
would not get the correct behavior that doX(b2) should invoke B2.x. This
is fixed by changing SILGen to emit class_method calls in protocol
methods for classes.
Swift SVN r16645
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
When we're using Objective-C's memory allocation, emit .cxx_construct
methods whenever we have instance variables with in-class
initializers. Presently, these methods are just empty stubs.
Swift SVN r12211
The Objective-C runtime executes the .cxx_destruct method after the
last -dealloc has executed when destroying an object, allowing the
instance variables to remain live even after the subclass's
destructor/-dealloc has executed, which is important for memory
safety. This fixes the majority of <rdar://problem/15136592>.
Note that IRGenModule::getAddrOfIVarDestroyer() contains an egregious
hack to find the ivar destructor SIL function via a linear
search. We need a better way to find SIL functions that we know exist,
because LinkEntity does not suffice.
Swift SVN r12206
SILDeclRef was previously storing the ClassDecl for this case, because
semantic analysis didn't guarantee that a DestructorDecl was always
present. It is now, and this representation makes more sense.
Swift SVN r12122
We were failing to capture generic parameters from closure contexts that themselves capture generic parameters from context. This fixes <rdar://problem/15417783>. While we're here, eliminate some unnecessary splitting of 'ClosureExpr' and 'AutoClosureExpr' in the SILDeclRef::Loc PointerUnion; we can just use their base class AbstractClosureExpr in the PointerUnion.
Swift SVN r10031
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
We already know how to call external functions in SILGen, why reimplement all that in IRGen? Instead of representing the thunk operation as a SIL instruction, let's just emit the thunk using existing SILGen machinery. Fixes <rdar://problem/14097136>.
Swift SVN r9576
When we walk a ClassDecl, generate its vtable, first pulling in decls from its ancestor classes, then overlaying overridden or new decls as we discover them.
Swift SVN r8947
These will provide a SIL-level representation of class_method dispatch, mapping from dynamically-dispatched SILDeclRefs to SILFunctions so that devirtualization passes will be able to promote a class_method for a statically-known type to a function_ref without going all the way back to the AST.
Swift SVN r8943
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
Doug pointed out that 'isObjC' incorrectly excludes C functions, for which we'll also need to be able to independently reference Swift and foreign entries.
Swift SVN r8669
We want the argument generator functions to be treated as transparent iff the "parent" function is transparent. There is no need to special case it in isTransparent because the SILDeclRef contains the :parent" Decl, and the first check will just work for us automatically.
Do make sure that the isTransparent is consulted when the apply instruction is created.
Swift SVN r8224
Thunks above the natural uncurry level of a function should always be emitted with standalone function CC instead of method or foreign CC. Partially addresses <rdar://problem/14687373>, but we still don't emit thunks for struct instance methods.
Swift SVN r8043
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
"SILConstant" doesn't really describe its role in SIL anymore, which is to provide a reference to a Swift declaration in a SIL instruction, such as a method or nominal type field.
Swift SVN r6559
