This is yet another waypoint on the path towards the final
generic-metadata design. The immediate goal is to make the
pattern a private implementation detail and to give the runtime
more visibility into the allocation and caching of generic types.
This makes resolving mangled names to nominal types in the same module more efficient, and for eventual secrecy improvements, also allows types in the same module to be referenced from mangled typerefs without encoding any source-level name information about them.
hasVtable is not initialized on all paths, so when we read it,
we end up reading a random value. On debug builds, this value
almost always happen to be zero, so we do the right thing. This
isn't necessarily true when the optimizations kick in.
lldb uses metadata reder to resolve types and as result of this
undefined behaviour sometimes gets wrong results back, causing
a bunch of tests to fail in release builds.
This new format more efficiently represents existing information, while
more accurately encoding important information about nested generic
contexts with same-type and layout constraints that need to be evaluated
at runtime. It's also designed with an eye to forward- and
backward-compatible expansion for ABI stability with future Swift
versions.
Various TypeDecoder clients will depend on having the "bare" nominal
type declaration demangled node for looking up nominal type descriptors,
so move the generic argument-stripping code into TypeDecoder.
TypeDecoder's interface with its builders already treated protocols as
a type (due to their being mangled as "protocol composition containing
one type"), and intermixed protocols with superclasses when forming
compositions. This makes for some awkwardness when working with
protocol descriptors, which are very much a distinct entity from a
type.
Separate out the notion of a "protocol declaration" (now represented
by the builder-provided BuiltProtocolDecl type) from "a protocol
composition containing a single type", similarly to the way we handle
nominal type declarations. Teach remote mirrors and remote AST to
handle the new contract.
The mangled name of protocol descriptors was the “protocol composition”
type consisting of a single protocol, which is a little odd. Instead,
use a bare protocol reference (e.g., “6Module5ProtoP”) with the “$S”
prefer to be more in line with nominal type descriptor names while still
making it clear that this is a Swift (not an Objective-C) protocol.
The remote reflection library has a fantastic utility class, TypeDecoder,
to take a mangled type and form an abstract type from it. Move this facility
into the Demangling library so other clients can use it.
If the nominal type descriptor's resilient superclass flag
is set, the generic parameter offset, vtable start offset
and field offset start offset are all relative to the
start of the class's immedaite members, and not the start
of the class metadata.
Support this by loading the size of the superclass and
adding it to these offsets if the flag is set.
We can reduce the uniquing header from 3–4 pointer-sized words down to 1–2 32-bit words + one pointer:
- The initialization function (when present) and name are always emitted into the same binary image, so we can use relative references to shrink these down to 32-bit fields.
- We don't ever simultaneously need the initialization flags and the initialized uniqued pointer. (Keeping the "initialization function" flag bit theoretically lets us turn a "consume" load into a "relaxed" load, but that makes no practical difference on most contemporary architectures.) 12 flag bits Ought To Be Enough For Anyone and lets us reliably tell a valid pointer from a flag set, so overlap the initialization flags with the eventual invasive cache value.
The invasive cache is left inline, since we've decided we're not going to make the rest of type metadata records ever be true-const, so they'll already be sitting on a dirty page. A dynamic linker that was sufficiently Swift-optimized to precalculate the other load-time-initialized entries in metadata could likely precompute the invasive cache value as well.
rdar://problem/22527141
Switch most general endpoint to be `flags, parameters, parameterFlags, result`,
instead of opaque `void **`, more specialized ones to use follow argument scheme:
`flags, param0, [flags0], ..., paramN, [flagsN], result` and store parameter/flags
information separately in `FunctionCacheEntry::{Key, Data}` as well.
Currently only single 'inout' flag has been encoded into function
metadata, these changes extend function metadata to support up to
32 flags per parameter.
Switch most general endpoint to be `flags, parameters, parameterFlags, result`,
instead of opaque `void **`, more specialized ones to use follow argument scheme:
`flags, param0, [flags0], ..., paramN, [flagsN], result` and store parameter/flags
information separately in `FunctionCacheEntry::{Key, Data}` as well.
Currently only single 'inout' flag has been encoded into function
metadata, these changes extend function metadata to support up to
32 flags per parameter.
Because `readMetadata` correctly reads tuple type metadata bounds,
there is no need to call for remote read of the memory allocated
for element types, since they are going to be laid out right after
tuple metadata itself and could be accessed using accessors in
`TargetTupleTypeMetadata`.
Support for @noescape SILFunctionTypes.
These are the underlying SIL changes necessary to implement the new
closure capture ABI.
Note: This includes a change to function name mangling that
primarily affects reabstraction thunks.
The new ABI will allow stack allocation of non-escaping closures as a
simple optimization.
The new ABI, and the stack allocation optimization, also require
closure context to be @guaranteed. That will be implemented as the
next step.
Many SIL passes pattern match partial_apply sequences. These all
needed to be fixed to handle the convert_function that SILGen now
emits. The conversion is now needed whenever a function declaration,
which has an escaping type, is passed into a @NoEscape argument.
In addition to supporting new SIL patterns, some optimizations like
inlining and SIL combine are now stronger which could perturb some
benchmark results.
These underlying SIL changes should be merged now to avoid conflicting
with other work. Minor benchmark discrepancies can be investigated as part of
the stack-allocation work.
* Add a noescape attribute to SILFunctionType.
And set this attribute correctly when lowering formal function types to SILFunctionTypes based on @escaping.
This will allow stack allocation of closures, and unblock a related ABI change.
* Flip the polarity on @noescape on SILFunctionType and clarify that
we don't default it.
* Emit withoutActuallyEscaping using a convert_function instruction.
It might be better to use a specialized instruction here, but I'll leave that up to Andy.
Andy: And I'll leave that to Arnold who is implementing SIL support for guaranteed ownership of thick function types.
* Fix SILGen and SIL Parsing.
* Fix the LoadableByAddress pass.
* Fix ClosureSpecializer.
* Fix performance inliner constant propagation.
* Fix the PartialApplyCombiner.
* Adjust SILFunctionType for thunks.
* Add mangling for @noescape/@escaping.
* Fix test cases for @noescape attribute, mangling, convert_function, etc.
* Fix exclusivity test cases.
* Fix AccessEnforcement.
* Fix SILCombine of convert_function -> apply.
* Fix ObjC bridging thunks.
* Various MandatoryInlining fixes.
* Fix SILCombine optimizeApplyOfConvertFunction.
* Fix more test cases after merging (again).
* Fix ClosureSpecializer. Hande convert_function cloning.
Be conservative when combining convert_function. Most of our code doesn't know
how to deal with function type mismatches yet.
* Fix MandatoryInlining.
Be conservative with function conversion. The inliner does not yet know how to
cast arguments or convert between throwing forms.
* Fix PartialApplyCombiner.
When the RemoteAST is used to access objects from LLDB, the object that
we are interacting with may not be a Swift object but rather an ObjC
object that has been bridged into swift. In such a case, the object
does not have a nominal type descriptor associated with it. Ensure that
the type is a valid Swift type before reading the nominal type
descriptor from the metadata. This avoids an assertion when evaluating
expressions in LLDB.
Alter the value metadata layout to use an absolute pointer for the
nominal type descriptor rather than a relative offset relative to the
complete type metadata. Although this is slightly less efficient in
terms of load times, this is more portable across different
environments. For example, PE/COFF does not provide a cross-section
relative offset relocation. Other platform ports are unable to provide
a 64-bit relative offset encoding.
Given that the value witness table reference in the value metadata is
currently an absolute pointer, this page is most likely going to be
dirtied by the loader.
Replace VariadicTuple and NonVariadicTuple with a single Tuple node.
The variadic property is now part of the tuple element and not of the whole tuple.
Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
This makes the demangler about 10 times faster.
It also changes the lifetimes of nodes. Previously nodes were reference-counted.
Now the returned demangle node-tree is owned by the Demangler class and it’s lifetime ends with the lifetime of the Demangler.
Therefore the old (and already deprecated) global functions demangleSymbolAsNode and demangleTypeAsNode are no longer available.
Another change is that the demangling for reflection now only supports the new mangling (which should be no problem because
we are generating only new mangled names for reflection).
Unfortunately, I'm flying blind a bit --- this code is hard to
test outside of an integrated environment on a target using the
ABI in question, and I don't have such an environment set up ---
so I'm left with this rather ugly process of iteratively submitting
patches for trivial bugs and waiting for the bots to deliver judgment.
The environment could be mocked with a test environment that used
a nonstandard ObjC ABI, but that would actually take a lot of work
because of Swift's assumptions about the ObjC ABI: we'd basically
have to configure the test environment as a real, proper target,
possibly all the way through LLVM.
