In regular swift this is a nice optimization. In embedded swift it's a requirement, because the compiler needs to be able to specialize generic deinits of non-copyable types.
The new de-virtualization utilities are called from two places:
* from the new DeinitDevirtualizer pass. It replaces the old MoveOnlyDeinitDevirtualization, which is very basic and does not fulfill the needs for embedded swift.
* from MandatoryPerformanceOptimizations for embedded swift
* add `NominalTypeDecl.isResilient`
* make the return type of `Type.getNominalFields` optional and return nil in case the nominal type is resilient.
This forces users of this API to think about what to do in case the nominal type is resilient.
A transformation must not create a `struct` instruction with a non-copyable type because this would apply that a (potential) deinit would be called for that struct.
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.
Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
Try to replace a begin_borrow with its owned operand.
This is either possible if the borrowed value (or a forwarded value if it) is copied:
```
%1 = begin_borrow %0
%2 = struct_extract %1 // a chain of forwarding instructions
%3 = copy_value %1
// ... uses of %3
end_borrow %1
```
->
```
%1 = copy_value %0
%3 = destructure_struct %0 // owned version of the forwarding instructions
// ... uses of %3
```
Or if the borrowed value is destroyed immediately after the borrow scope:
```
%1 = begin_borrow %0
%2 = struct_extract %1 // a chain of forwarding instructions
// ... uses of %2
end_borrow %1
destroy_value %1 // the only other use of %0 beside begin_borrow
```
->
```
%2 = destructure_struct %0 // owned version of the forwarding instructions
// ... uses of %2
destroy_value %2
```
Make filter APIs for UseList chainable by adding them to Sequence where Element == Operand
For example, it allows to write:
```
let singleUse = value.uses.ignoreDebugUses.ignoreUsers(ofType: EndAccessInst.self).singleUse
```
Also, add `UseList.getSingleUser(notOfType:)`
When merging stores in a global initializer, it's possible that the merged store is inserted at the wrong location, causing a SIL verifier error.
This is hard to reproduce, but can happen.
The merged store must be inserted _after_ all other stores. Instead it's inserted after the store of the last property. Now, if properties are _not_ initialized in the order they are declared, this problem can show up.
rdar://117189962
In the C++ sources it is slightly more convenient to dump to stderr than
to print to stdout, but it is rather more unsightly to print to stderr
from the Swift sources. Switch to stdout. Also allows the dump
functions to be marked debug only.
Introduce two modes of bridging:
* inline mode: this is basically how it worked so far. Using full C++ interop which allows bridging functions to be inlined.
* pure mode: bridging functions are not inlined but compiled in a cpp file. This allows to reduce the C++ interop requirements to a minimum. No std/llvm/swift headers are imported.
This change requires a major refactoring of bridging sources. The implementation of bridging functions go to two separate files: SILBridgingImpl.h and OptimizerBridgingImpl.h.
Depending on the mode, those files are either included in the corresponding header files (inline mode), or included in the c++ file (pure mode).
The mode can be selected with the BRIDGING_MODE cmake variable. By default it is set to the inline mode (= existing behavior). The pure mode is only selected in certain configurations to work around C++ interop issues:
* In debug builds, to workaround a problem with LLDB's `po` command (rdar://115770255).
* On windows to workaround a build problem.
This could be combined with ValueUseDefWalker if the latter is
refactored to classsify instructions by projections and aggegation
(which always forward) vs. other arbitrary hard-coded instruction
types. It would also need to limit the walk to real operands (which
are always forwarded). Then this walker can call into the default walk
for projections and track the projection path. The current
implementation is however simpler and more efficient.
All SILArgument types are "block arguments". There are three kinds:
1. Function arguments
2. Phis
3. Terminator results
In every situation where the source of the block argument matters, we
need to distinguish between these three. Accidentally failing to
handle one of the cases is an perpetual source of compiler
bugs. Attempting to handle both phis and terminator results uniformly
is *always* a bug, especially once OSSA has phi flags. Even when all
cases are handled correctly, the code that deals with data flow across
blocks is incomprehensible without giving each case a type. This
continues to be a massive waste of time literally every time I review
code that involves cross-block control flow.
Unfortunately, we don't have these C++ types yet (nothing big is
blocking that, it just wasn't done). That's manageable because we can
use wrapper types on the Swift side for now. Wrapper types don't
create any more complexity than protocols, but they do sacrifice some
usability in switch cases.
There is no reason for a BlockArgument type. First, a function
argument is a block argument just as much as any other. BlockArgument
provides no useful information beyond Argument. And it is nearly
always a mistake to care about whether a value is a function argument
and not care whether it is a phi or terminator result.
For chains of async functions where suspensions can be statically
proven to never be required, this pass removes all suspensions and
turns the functions into synchronous functions.
For example, this function does not actually require any suspensions,
once the correct executor is acquired upon initial entry:
```
func fib(_ n: Int) async -> Int {
if n <= 1 { return n }
return await fib(n-1) + fib(n-2)
}
```
So we can turn the above into this for better performance:
```
func fib() async -> Int {
return fib_sync()
}
func fib_sync(_ n: Int) -> Int {
if n <= 1 { return n }
return fib(n-1) + fib(n-2)
}
```
while rewriting callers of `fib` to use the `sync` entry-point
when we can prove that it will be invoked on a compatible executor.
This pass is currently experimental and under development. Thus, it
is disabled by default and you must use
`-enable-experimental-async-demotion` to try it.
The walker was not treating an EnumInst with zero payload, such as `Optional.none` as a root.
It seems the best way to fix that is to implement the handling of .anyValueFields for enums, as
they're documented in a comment to mean "follow anything", unlike .enumCase which expects
to find a specific case (though perhaps if it matches and there's no payload, it should still be a root?)
