Start building the dynamic exclusivity checking code in Embedded Swift.
It will be used when dynamic exclusivity checking is enabled (via
`-enforce-exclusivity=checked`), and dead-code-stripped otherwise. Note
that we deliberately avoid linking `swift_(begin|end)Access` in
modules that don't have exclusivity enforcement enabled to aid with
dead-code stripping.
Also note that, unlike in non-Embedded Swift, exclusivity checking
cannot be disabled at runtime by setting
_swift_disableExclusivityChecking to `false`. We need the ability to
constant-initialize global variables to bring that functionality into
Embedded Swift.
Tracked by rdar://159115910.
Although this error can only happen when tinkering with the stdlib's runtime functions, it's nice to get a readable error message. So far, the compiler just crashed later without a hint to the original problem.
Whenever we have a reference to a foreign function/variable in SIL, use
a mangled name at the SIL level with the C name in the asmname
attribute. The expands the use of asmname to three kinds of cases that
it hadn't been used in yet:
* Declarations imported from C headers/modules
* @_cdecl @implementation of C headers/modules
* @_cdecl functions in general
Some code within the SIL pipeline makes assumptions that the C names of
various runtime functions are reflected at the SIL level. For example,
the linking of Embedded Swift runtime functions is done by-name, and
some of those names refer to C functions (like `swift_retain`) and
others refer to Swift functions that use `@_silgen_name` (like
`swift_getDefaultExecutor`). Extend the serialized module format to
include a table that maps from the asmname of functions/variables over
to their mangled names, so we can look up functions by asmname if we
want. These tables could also be used for checking for declarations
that conflict on their asmname in the future. Right now, we leave it
up to LLVM or the linker to do the checking.
`@_silgen_name` is not affected by these changes, nor should it be:
that hidden feature is specifically meant to affect the name at the
SIL level.
The vast majority of test changes are SIL tests where we had expected
to see the C/C++/Objective-C names in the tests for references to
foreign entities, and now we see Swift mangled names (ending in To).
The SIL declarations themselves will have a corresponding asmname.
Notably, the IRGen tests have *not* changed, because we generally the
same IR as before. It's only the modeling at the SIL lever that has
changed.
Another part of rdar://137014448.
Removes the underscored prefixes from the @_section and @_used attributes, making them public as @section and @used respectively. The SymbolLinkageMarkers experimental feature has been removed as these attributes are now part of the standard language. Implemented expression syntactic checking rules per SE-0492.
Major parts:
- Renamed @_section to @section and @_used to @used
- Removed the SymbolLinkageMarkers experimental feature
- Added parsing support for the old underscored names with deprecation warnings
- Updated all tests and examples to use the new attribute names
- Added syntactic validation for @section to align with SE-0492 (reusing the legality checker by @artemcm)
- Changed @DebugDescription macro to explicitly use a tuple type instead of type inferring it, to comply with the expression syntax rules
- Added a testcase for the various allowed and disallowed syntactic forms, `test/ConstValues/SectionSyntactic.swift`.
The test was crashing due to `swift_unreachable("custom executors not supported in embedded Swift")` line in `swift_task_enqueueImpl`, as the corresponding non-embedded codepath was relying on an unspecialized generic function `_swift_task_enqueueOnExecutor` defined in `Executor.swift`. Unspecialized generics are unavailable in Embedded Swift, and such `@silgen_name` function can't be specialized when used from concurrency runtime code written in C/C++. We can redefine this function for Embedded Swift as using a class-bound existential instead, and re-enable this codepath with a slightly different call that avoids the use of unavailable `swift_getObjectType` function from the non-embedded runtime.
We need to explicitly link `swift_asyncMainDrainQueueImpl` and
`swift_createDefaultExecutors` since those two do not have Concurrency
hooks and so aren't linked automatically by the macro-processing code.
This adjusts the runtime function declaration handling to track the
owning module for the well known functions. This allows us to ensure
that we are able to properly identify if the symbol should be imported
or not when building the shared libraries. This will require a
subsequent tweak to allow for checking for static library linkage to
ensure that we do not mark the symbol as DLLImport when doing static
linking.
In embedded swift all de-serialized get public linkage because all the code is generated in the top-level module.
This change moves the point where we make de-serialized functions public to the end of the pipeline.
This allows dead function elimination to remove unused de-serialized functions.
For some stdlib functions (actually one: the Double initializer for a builtin integer) is essential, because codegen for embedded produces an unresolved symbol.
rdar://123772098
Link.cpp started pulling in the macros from RuntimeFunctions.def, which
do not include memory effects on main, but do on rebranch. This resulted
in build failures due to extra parameters to the macro function.
As a first step to getting mandatory inlining out of the business
of 'linking' (walking the function graph and deserializing all
referenced functions), add a new optimizer pass which links
everything in the mandatory pipeline.
For now this is mostly NFC, except it regresses an optimization
I made recently by linking in bodies of methods of deserialized
vtables eagerly. This will be addressed in upcoming patches.
As a first step to getting mandatory inlining out of the business
of 'linking' (walking the function graph and deserializing all
referenced functions), add a new optimizer pass which links
everything in the mandatory pipeline.
For now this is mostly NFC, except it regresses an optimization
I made recently by linking in bodies of methods of deserialized
vtables eagerly. This will be addressed in upcoming patches.
It was only used in a few tests. Those tests now use -emit-sil instead
of -emit-silgen, with some functions marked @_transparent and a few
CHECK: lines changed now that the mandatory optimizations get to run.
At some point, pass definitions were heavily macro-ized. Pass
descriptive names were added in two places. This is not only redundant
but a source of confusion. You could waste a lot of time grepping for
the wrong string. I removed all the getName() overrides which, at
around 90 passes, was a fairly significant amount of code bloat.
Any pass that we want to be able to invoke by name from a tool
(sil-opt) or pipeline plan *should* have unique type name, enum value,
commend-line string, and name string. I removed a comment about the
various inliner passes that contradicted that.
Side note: We should be consistent with the policy that a pass is
identified by its type. We have a couple passes, LICM and CSE, which
currently violate that convention.
There are now separate functions for function addition and deletion instead of InvalidationKind::Function.
Also, there is a new function for witness/vtable invalidations.
rdar://problem/29311657
(libraries now)
It has been generally agreed that we need to do this reorg, and now
seems like the perfect time. Some major pass reorganization is in the
works.
This does not have to be the final word on the matter. The consensus
among those working on the code is that it's much better than what we
had and a better starting point for future bike shedding.
Note that the previous organization was designed to allow separate
analysis and optimization libraries. It turns out this is an
artificial distinction and not an important goal.