When we generate code that asks for complete metadata for a fully concrete specific type that
doesn't have trivial metadata access, like `(Int, String)` or `[String: [Any]]`,
generate a cache variable that points to a mangled name, and use a common accessor function
that turns that cache variable into a pointer to the instantiated metadata. This saves a bunch
of code size, and should have minimal runtime impact, since the demangling of any string only
has to happen once.
This mostly just works, though it exposed a couple of issues:
- Mangling a type ref including objc protocols didn't cause the objc protocol record to get
instantiated. Fixed as part of this patch.
- The runtime type demangler doesn't correctly handle retroactive conformances. If there are
multiple retroactive conformances in a process at runtime, then even though the mangled string
refers to a specific conformance, the runtime still just picks one without listening to the
mangler. This is left to fix later, rdar://problem/53828345.
There is some more follow-up work that we can do to further improve the gains:
- We could improve the runtime-provided entry points, adding versions that don't require size
to be cached, and which can handle arbitrary metadata requests. This would allow for mangled
names to also be used for incomplete metadata accesses and improve code size of some generic
type accessors. However, we'd only be able to take advantage of the new entry points in
OSes that ship a new runtime.
- We could choose to always symbolic reference all type references, which would generally reduce
the size of mangled strings, as well as make runtime demangling more efficient, since it wouldn't
need to hit the runtime caches. This would however require that we be able to handle symbolic
references across files in the MetadataReader in order to avoid regressing remote mirror
functionality.
Validation of the input side of FunctionTypeRepr was previously being done in Sema because of expression folding. If we instead push the invariant that the input TypeRepr should always be a TupleTypeRepr into the AST a number of nice cleanups fall out:
- The SIL Parser no longer accepts Swift 2-style type declarations
- Parse is more cleanly able to reject invalid FunctionTypeReprs
- Clients of the AST can be assured the input type is always a TupleType so we can flush Swift 2 hacks
Avoid a temporary file and executing FileCheck multiple types and prefer
multiple check prefixes and streaming. Additionally, enable some of
previously XFAIL'ed tests on Linux as well as tests that were marked as
requiring Objective-C interop.
This adds the dllstorage annotations on the tests. This first pass gets
most of the IRGen tests passing on Windows (though has dependencies on
other changes). However, this allows for the changes to be merged more
easily as we cannot regress other platforms here.
This ABI endpoint is used to retrieve metadata about functions
without parameters. Which is very common use-case and it
makes sense to save some code size for that.
This changes layout of the `TargetFunctionTypeFlags` to allocate
8 bits for flags, 8 bits for convesion and 16 bits for number of
parameters. Documentation is updated accordingly.
This changes layout of the parameter metadata from single tuple record
(in case of materializable type) to N records each corresponding to
invididual function parameter, where functions with no parameters
`() -> Void` get 0 records allocated.
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
This prevents the linker from trying to emit relative relocations to locally-defined public symbols into dynamic libraries, which gives ld.so heartache.
@inout parameters can be nocapture and dereferenceable. @in, @in_guaranteed, and indirected @direct parameters can be noalias, nocapture, and dereferenceable.
Swift SVN r29353
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
We have enough flag bits on function types now to warrant stashing an extra word in the metadata key alongside the arguments and results, so add one, and pack the number of arguments, function convention, and 'throws' bit in there. This lets us merge the separate metadata caches for thick/thin/block/C functions into one, saving a bit of runtime memory, and simplifying a bunch of repetitive code in the runtime and IRGen.
This also fixes a subtle bug we had where the runtime getFunctionTypeMetadata function expected the result argument to be passed in the arguments array, but IRGen was passing it as a separate argument, which would have caused function type metadata to fail to be uniqued by result type.
Swift SVN r27651
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
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
Blocks need their own type metadata with value witnesses appropriate to the block representation. Fixes <rdar://problem/16918740> and <rdar://problem/16981126>.
Swift SVN r18508
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
Add a 'Block' ExtraData kind, and teach IRGen how to pull the invocation pointer out of a block structure and pass the block object in the right place.
Swift SVN r13940
