dynamic-replacement runtime functions.
The recent change of how we do dynamic replacements added 2 new runtime
functions. This patch adds those functions to the Compatibility50 static
archive.
This will allow backward deployment to a swift 5.0 runtime.
Patch by Erik Eckstein with a modification to call the standard
libraries implementation (marked as weak) when it is available.
This ensures we can change the implementation in the future and are not
ABI locked.
rdar://problem/51601233
When backward deploying to an OS that may not have these entry points, weak-link them so that they
can be used conditionally in availability contexts that check for them.
rdar://problem/50731151
When Swift always copied the overlay dylibs into app bundles, it was OK
for these symbol references to be non-weak, but with the overlays now
part of the OS on Apple platforms, we need to handle backward deployment
scenarios where a new overlay does not exist on an old OS version.
A weak reference will serve to pull in the overlay dylib if it exists,
without causing a fatal error if it does not. rdar://problem/50110036
Create two new semantic names: `ExternalImport` and `ExternalExport`.
These are for symbols which are either imported from an external module
or exported for consumption by external modules.
Now that DLLStorage is only applied when needed, always pass the correct
DLLStorage. The IRLinkage applicator will determine if the DLLStorage
should be applied or not.
Use `ApplyIRLinkage` to the force load thunks to permit multiple
emissions to be COMDATed on Windows. The multi-module tests would emit
the symbols multiply and would fail to link.
This is actually NFC: We should have already deserialized everything
we need at this point, and because of large loadable types and
address lowering, deserializing more stuff in IRGen is not valid,
and in fact we check for this and refuse to deserialize.
This is essentially a long-belated follow-up to Arnold's #12606.
The key observation here is that the enum-tag-single-payload witnesses
are strictly more powerful than the XI witnesses: you can simulate
the XI witnesses by using an extra case count that's <= the XI count.
Of course the result is less efficient than the XI witnesses, but
that's less important than overall code size, and we can work on
fast-paths for that.
The extra inhabitant count is stored in a 32-bit field (always present)
following the ValueWitnessFlags, which now occupy a fixed 32 bits.
This inflates non-XI VWTs on 32-bit targets by a word, but the net effect
on XI VWTs is to shrink them by two words, which is likely to be the
more important change. Also, being able to access the XI count directly
should be a nice win.
- fix code generation for enum types to zext or trunc 32 bit data as appropriate for the platform
- fix IR generation code to use a relative address type of 16 bit width on that platform
- correct order of statements and line up comments
A dynamically replaceable function calls through a global variable that
holds the function pointer.
struct ChainEntry {
void *(funPtr)();
struct ChainEntry *next;
}
ChainEntry dynamicallyReplaceableVar;
void dynamicallyReplaceableFunction() {
dynamicallyReplaceableVar.funPtr()
}
dynamic replacements will be chainable so the global variable also
functions as the root entry in the chain of replacements.
A dynamic replacement functions can call the previous implementation by
going through its chain entry.
ChainEntry chainEntryOf_dynamic_replacement_for_foo;
void dynamic_replacement_for_foo() {
// call the previous (original) implementation.
chainEntryOf_dynamic_replacement_for_foo.funPtr();
}
