We previously eagerly emitted such functions to
ensure that their name data is emitted through the
profiler increment. Now that are able to emit the
profile name data separately, this is unnecessary,
and we can avoid emitting their definitions.
llvm/llvm-project `3131714f8daca338492a7d5b189e4d63131bc808` changed
`ModuleAddressSanitizerPass` to take an `AddressSanitizerOptions`
instead. `b7fd30eac3183993806cc218b6deb39eb625c083` also removed
`AddressSanitizerPass` after it was rolled into
`ModuleAddressSanitizerPass` in
`b7fd30eac3183993806cc218b6deb39eb625c083`.
Update IRGen to use the new options and remove the additional pass.
See #59144 for more on why this is a bad idea.
Patch out the synthesized file unit accessor to only clear the source cache, then patch up all the places that were assuming they could iterate over the module's file list and see synthesized files.
rdar://94164512
Don't run the objc-arc-contract pass when disable-llvm-optzns is passed.
In pipeline setups where the swift-frontend is called twice;
- the first time to create bitcode
- the second time to generate object code from the bitcode (using
disable-llvm-optzns)
we don't want to run the objc-arc-contract pass twice.
rdar://91908312
LTO pipeline requires consistent `EnableSplitLTOUnit` and module summary
in regular full LTO bitcode, and clang enables `EnableSplitLTOUnit` and
emit regular lto module summary on non-ld64 platforms.
Therefore, swiftc has to emit them for the consistency with clang.
This has a few nice benefits:
1. The splitting happens after LLVM optimizations have run. This ensures that
LLVM will not join these blocks no matter what! The author of this commit has
found that in certain cases LLVM does this even at -Onone. By running this late,
we get the benefit we are looking for: working around the bad SelectionDAG
behavior.
2. This block splitting is just a workaround for the above mentioned unfortunate
SelectionDAG behavior. By doing this when we remove the workaround, we will not
have to update SIL level tests... instead we will just remove a small LLVM pass.
Some additional notes:
1. Only moved values will ever have llvm.dbg.addr emitted today, so we do not
have to worry about this impacting the rest of the language.
2. The pass's behavior is tested at the IR level by move_function_dbginfo.swift.
PublicCMOSymbols stores symbols which are made public by cross-module-optimizations.
Those symbols are primarily stored in SILModule and eventually used by TBD generation and validation.
Uses a dedicated section in the binary to emit records about
functions that can be looked up by name at the runtime, and
then called through a fully-abstracted entry point whose
arguments can be constructed in code.
Leaks checking is not thread safe and e.g. lldb creates multiple SILModules in multiple threads, which would result in false alarms.
Ideally we would make it thread safe, e.g. by putting the instruction counters in the SILModule, but this would be a big effort and it's not worth doing it. Leaks checking in the frontend's and SILOpt's SILModule (not including SILModules created for module interface building) is a good enough test.
rdar://84688015
@objc actors implicitly inherit from the new, hidden
`SwiftNativeNSObject` class that inherits from `NSObject` yet provides
Swift-native reference counting, which is important for the actor
runtime's handling of zombies. However, `SwiftNativeNSObject` is only
available in the Swift runtime in newer OS versions (e.g., macOS
12.0/iOS 15.0), and is available in the back-deployed _Concurrency
library, but there is no stable place to link against for
back-deployed code. Tricky, tricky.
When back-deploying @objc actors, record `NSObject` as the superclass
in the metadata in the binary, because we cannot reference
`SwiftNativeNSObject`. Then, emit a static initializer to
dynamically look up `SwiftNativeNSObject` by name (which will find it
in either the back-deployment library, on older systems, or in the
runtime for newer systems), then swizzle that in as the superclass of
the @objc actor.
Fixes rdar://83919973.
A new LLVM IR affordance that allows expressing conditions under which globals
can be removed/dropped (even when marked with @llvm.used) is being discussed at:
- <https://reviews.llvm.org/D104496>
- <https://lists.llvm.org/pipermail/llvm-dev/2021-September/152656.html>
This is a preliminary implementation that marks runtime lookup records (namely
protocol records, type descriptors records and protocol conformance records)
with the !llvm.used.conditional descriptors. That allows link-time / LTO-time
removal of these records (by GlobalDCE) based on whether they're actually used
within the linkage unit. Effectively, this allows libraries that have a limited
and known set of clients, to be optimized against the client at LTO time, and
significantly reduce the code size of that library.
Parts of the implementation:
- New -conditional-runtime-records frontend flag to enable using !llvm.used.conditional
- IRGen code that emits these records can now emit these either as a single contiguous
array (asContiguousArray = true, the old way), which is used for JIT mode, or
as indivial globals (asContiguousArray = false), which is necessary for the
!llvm.used.conditional stripping to work.
- When records are emitted as individual globals, they have new names of
"\01l_protocol_" + mangled name of the protocol descriptor, and similarly for
other records.
- Fixed existing tests to account for individual records instead of a single array
- Added an IR level test, and an end-to-end execution test to demonstrate that
the !llvm.used.conditional-based stripping actually works.
- Witness method calls are done via @llvm.type.checked.load instrinsic call with a type identifier
- Type id of a witness method is the requirement's mangled name
- Witness tables get !type markers that list offsets and type ids of all methods in the wtable
- Added -enable-llvm-wme to enable Witness Method Elimination
- Added IR test and execution test
control swift extended frame information emission
On linux we default to disable the extended frame info (since the system
libraries don't support it).
On darwin the default is to automatically choose based on the deployment target.
The Concurrency library explicitly forces extended frame information and the
back deployment library explicitly disables it.
- Virtual calls are done via a @llvm.type.checked.load instrinsic call with a type identifier
- Type identifier of a vfunc is the base method's mangling
- Type descriptors and class metadata get !type markers that list offsets and type identifiers of all vfuncs
- The -enable-llvm-vfe frontend flag enables VFE
- Two added tests verify the behavior on IR and by executing a program
