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();
}
We were using this just as a convenient way to share an existing
DenseMap, but it's not really related; we don't need to compute
witness table layout just to generate a conformance reference.
I started working on this because the "Cub" source compat project was
hitting issues here, but now I can't reproduce it. Still, this is a
reasonable cleanup.
Previously, when a tuple type had non-fixed layout, we would compute
a layout by building the metadata for that tuple type and then
extracting the layout from the VWT. This can be quite expensive
because it involves constructing the exact metadata for types like
arrays and functions despite those types being fixed-layout across
all instantiations. It also tends to cause unnecessary recursive-type
issues, especially with enums where tuples are currently used to model
cases with mutliple payloads. Since we just need a layout, computing
it directly from element layouts instead of constructing metadata for
the formal type lets us take advantage of all the other fast paths for
layout construction, e.g. for fixed types and single-field aggregates.
This is a good improvement overall, but it also serves to alleviate
some of the problems of rdar://40810002 / SR-7876 in a way that
might be suitable for integration to 4.2.
Because the runtime is compacted into the standard library, functions
which are normally imported are actually local definitions. Use module
level named metadata to identify the module as being the swift standard
library. Refactor the condition slightly to improve code readability.
This addresses SR-7107!
We use dummy symbols to force overlays not to get dropped when
autolinking, even if the user doesn't use anything from them
explicitly. This behavior is triggered by the semi-hidden flag
-autolink-force-load.
(It's semi-hidden because it has few legitimate uses in real life. If
you searched for "how to force autolinking to pick up a library" and
found this commit, don't just do this and move on. Come talk to me on
forums.swift.org.)
Previously we added these dummy symbols to every object file using
"common" linkage, a little-known feature added for C that ensures that
only one definition will actually get used in the final object file.
However, the way we were doing that wouldn't work so well for COFF,
and so in 1025eed64 Saleem changed this to use "weak ODR" linkage.
This has *nearly* the same effect, and avoids some other weirdness,
but has the downside of making the symbol in the final dylib "weak"
itself, meaning that some /other/ library could come along and
override it. That impacts loading time, and an Apple-internal tool
caught that as rdar://39019606.
To avoid this whole mess, "just" emit the symbol into the object file
that corresponds to the first file in the module, which allows us to
mark it as a normal public symbol.
P.S. None of this is actually important at the moment because all of
the overlays are built with single-threaded WMO, which always produces
one object file anyway. But I wanted to get it right once and for all.
