Instead of a wholly separate lazyness mechanism for foreign metadata where
the first call to getAddrOfForeignTypeMetadataCandidate() would emit the
metadata, emit it using the lazy metadata mechanism.
This eliminates some code duplication. It also ensures that foreign
metadata is only emitted once per SIL module, and not once per LLVM
module, avoiding duplicate copies that must be ODR'd away in multi-threaded
mode.
This fixes the test case from <rdar://problem/49710077>.
These functions don't accept local variable heap memory, although the names make it sound like they work on anything. When you try, they mistakenly identify such things as ObjC objects, call through to the equivalent objc_* function, and crash confusingly. This adds Object to the name of each one to make it more clear what they accept.
rdar://problem/37285743
- `swift_getForeignTypeMetadata` is now a request/response function.
- The initialization function is now a completion function, and the
pointer to it has moved into the type descriptor.
- The cache variable is no longer part of the ABI; it's an
implementation detail of the access function.
- The two points above mean that there is no special header on foreign
type metadata and therefore that they can be marked constant when
there isn't something about them that needs to be initialized.
The only foreign-metadata initialization we actually do right now is
of the superclass field of a foreign class, and since that relationship
is a proper DAG, it's not actually possible to have recursive
initialization problems. But this is the right long-term thing to do,
and it removes one of the last two clients of once-based initialization.
It hass been a longstanding principle in LLVM that the presence of
debug info shall not affect code generation. This patch brings the
Swift frontend closer to this ideal:
- unconditionally emit shadow copies
- unconditionally bind type metadata
The extra allocas, bitcasts, geps, and stores being emitted get
optimized away when compiling at anything but -Onone. There are few
use-cases for compiling at -Onone without -g, so this shouldn't affect
performance for any real-world use-cases.
I am going to leave in the infrastructure around this just in case. But there is
no reason to keep this in the tests themselves. I can always just revert this
and I don't think merge conflicts are likely due to previous work I did around
the tooling for this.
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
This reverts commit 25985cb764. For now,
we're trying to avoid spurious non-structural changes to the mangling,
so that the /old/ mangling doesn't appear to change. That doesn't mean
no changes at all, but we can save this one for later.
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
Often times SILGen wants to hold onto values that have been copied. This causes
an issue, when due to Cleanups firing, SILBuilder inserts destroys and destroys
the copy that produced the value that SILGen held onto. This will then cause
SILGen to emit incorrect code.
There really is no reason to introduce such complexity into SILBuilder when a
small simple guaranteed pass can perform the same work. Thus the introduction of
this pass.
In a later commit, I am going to eliminate the SILBuilder entry points.
rdar://28685236
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
This was previously bumped to move from Swift 1.2 to 2.0. Time for 3.0.
Note, unlike last time (136965d9f8), the
CMakeLists.txt change already says 3.0 so that won't get changed here.
