If a pass forgot to call invalidateAnalysis but deleted some instructions, the pass-manager can fix this.
Currently following passes do not invalidate analysis when they change the SIL:
* LowerTupleAddrConstructor
* DestroyAddrHoisting
* MoveOnlyChecker
* PredictableDeadAllocationElimination
Ideally we should fix those passes. But with this addition in the pass-manager it's not strictly necessary.
Fixes a compiler crash.
This ended up in creating a lot of Array functions, even if a program didn't use Array at all.
Now, only add specialization attributes if a function is already there.
Otherwise remember the attributes and add them to a function once it is created.
In Embedded Swift, witness method lookup is done from specialized witness tables.
For this to work, the type of witness_method must be specialized as well.
Otherwise the method call would be done with wrong parameter conventions (indirect instead of direct).
The main change here is to associate a witness table with a `ProtocolConformance` instead of a `RootProtocolConformance`.
A `ProtocolConformance` is the base class and can be a `RootProtocolConformance` or a `SpecializedProtocolConformance`.
For years, optimizer engineers have been hitting a common bug caused by passes
assuming all SILValues have a parent function only to be surprised by SILUndef.
Generally we see SILUndef not that often so we see this come up later in
testing. This patch eliminates that problem by making SILUndef uniqued at the
function level instead of the module level. This ensures that it makes sense for
SILUndef to have a parent function, eliminating this possibility since we can
define an API to get its parent function.
rdar://123484595
It's not thread safe and can cause false alarms in case multiple modules exist in different threads. E.g. when building swiftmodules from interfaces.
The leaking check is not important anymore because the builder APIs enforce that instructions are not leaking.
I.e. it's not possible to create an instruction without inserting it into a basic block. Also, it's not possible to remove an instruction from a block without deleting it.
rdar://122169263
To verify if a function may read from an indirect argument, don't use AliasAnalysis.
Instead use the CalleeCache to get the list of callees of an apply instruction.
Then use a simple call-back into the swift Function to check if a callee has any relevant memory effect set.
This avoids a dependency from SIL to the Optimizer.
It fixes a linker error when building some unit tests in debug.
`getRootLocalArchetypeDef()` may return a `PlaceholderValue` which makes the
`cast<SingleValueInstruction>` invalid. Use `dyn_cast` and then update the
callers of `getRootLocalArchetypeDefInst()` to handle `nullptr`.
Deserialization is calling AccessMarkerElimination repeatedly on the
same function.
The bug was introduced here:
commit 872bf40e17
Date: Mon Aug 13 10:24:20 2018
[sil-optimizer] Centralize how we send out serialization notifications.
Where the code that uniques the deserialization callbacks was simply
removed!
As a result, this pass was being invoked a number of times equal to
the number of functions in the module *multiplied* by the number of
functions being deserialized.
Fixes rdar://117141871 (Building spends most of its time in
AccessMarkerElimination)
- VTableSpecializer, a new pass that synthesizes a new vtable per each observed concrete type used
- Don't use full type metadata refs in embedded Swift
- Lazily emit specialized class metadata (LazySpecializedClassMetadata) in IRGen
- Don't emit regular class metadata for a class decl if it's generic (only emit the specialized metadata)
Introduce `AvailableDuringLoweringDeclFilter` which can be composed with
`OptionalTransformRange` to implement iterators that filter out unavailable
decls.
Moving the query implementation up to the AST library from SIL will allow
conveniences to be written on specific AST element classes. For instance, this
will allow `EnumDecl` to expose a convenience that enumerates element decls
that are available during lowering.
Also, improve naming and documentation for these queries.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Data structures must be layout compatible when built with and without asserts.
Fixes a compiler crash when C++ sources are built without asserts because SwiftCompilerSources are built with asserts.
rdar://110363377
When `-unavailable-decl-optimization=complete` is specified, exclude
unavailable enum cases from the runtime layout of enums with payloads. Without
this, the type metadata for unavailable types may be referenced by enum cases
with unavailable payloads and cause linker failures.
Resolves rdar://107483852
When `-unavailable-decl-optimization=stub` is specified, insert a call to
`_diagnoseUnavailableCodeReached()` at the beginning of the function to cause
it to trap if executed at run time.
Part of rdar://107388493
Optimizations can rely on alias analysis to know that an in-argument (or parts of it) is not actually read.
We have to do the same in the verifier: if alias analysis says that an in-argument is not read, there is no need that the memory location is initialized.
Fixes a false verifier error.
rdar://106806899
Add a separate 'verifyOwnership()' entry point so it's possible
to check OSSA lifetimes at various points.
Move SILGenCleanup into a SILGen pass pipeline.
After SILGen, verify incomplete OSSA.
After SILGenCleanup, verify ownership.
When opaque values are enabled, TypeConverter associates to an
address-only type an OpaqueValueTypeLowering. That lowering stores a
single lowered SIL type, and its value category is "object". So long as
the module has not yet been address-lowered, that type has the
appropriate value category. After the module has been address-lowered,
however, that type has the wrong value category: the type is
address-only, and in an address-lowered module, its lowered type's value
category must be "address".
Code that obtains a lowered type expects the value category to reflect
the state of the module. So somewhere, it's necessary to fixup that
single lowered type's value category.
One option would be to update all code that uses lowered types. That
would require many changes across the codebase and all new code that
used lowered types would need to account for this.
Another option would be to update some popular conveniences that call
through to TypeConverter, for example those on SILFunction, and ensure
that all code used those conveniences. Even if this were done
completely, it would be easy enough for new code to be added which
didn't use the conveniences.
A third option would be to update TypeLowering::getLoweredType to take
in the context necessary to determine whether the stored SILType should
be fixed up. That would require each callsite to be changed and
potentially to carry around more context than it already had in order to
be able to pass it along.
A fourth option would be to make TypeConverter aware of the
address-loweredness, and to update its state at the end of
AddressLowering.
Updating TypeConverter's state would entail updating all cached
OpaqueValueTypeLowering instances at the end of the AddressLowering
pass. Additionally, when TypeConverter produces new
OpaqueValueTypeLowerings, they would need to have the "address" value
category from creation.
Of all the options, the last is least invasive and least error-prone, so
it is taken here.
Specifically, we get an additional table like thing called sil_moveonlydeinit. It looks as follows:
sil_moveonlydeinit TYPE {
@FUNC_NAME
}
It always has a single entry.
* move the source file to SILOptimizer/IRGenTransforms
* add a file level comment
* document and verify that the pass runs after serialization
* catch overflows when truncating a constant value
As we do with field indices for struct instructions.
This avoids quadratic behavior in case of enums with lots of cases.
Also: cache field and enum case indices in the SILModule.
