Looking at the SIL I came to the conclusion that `Unmanaged` ins fundamentally broken.
It's easier to directly bitcast between bridged and native SIL objects. It also produces simpler SIL which can be further optimized
Instead of doing the type casts and/or conformance lookup on the swift side, do it on the C++ side.
It makes a significant performance difference because `Operand.value` is a time critical function
The run time of `Value.hasTrivialNonPointerType` is not negligible, because it does a cache lookup of type lowerings.
Only do this check if it's really needed.
The `isEscaping` function is called a lot from ARCSequenceOpt and ReleaseHoisting.
To avoid quadratic complexity for large functions, limit the amount of work what the EscapeUtils are allowed to to.
This keeps the complexity linear.
The arbitrary limit is good enough for almost all functions.
It lets the EscapeUtils do several hundred up/down walks which is much more than needed in most cases.
Fixes a compiler hang
https://github.com/apple/swift/issues/63846
rdar://105795976
The instance type of a metatype instruction is not necessarily a legal lowered SIL Type.
Lower the type before converting it to a SILType.
rdar://105502403
When walking up we shouldn't end up at a load where followLoads is false, because going from a (non-followLoads) address to a load always involves a class indirection.
There is one exception: loading a raw pointer
* Disallow stores in the return -> argument path. When walking up in the EscapeUtils, it's allowed to follow stores. Therefore stores wouldn't be handled correctly.
* Also make sure that there is a return -> argument path at all
Fixes a wrong address-escaping effect in case the called function copies an indirect argument to a newly created object.
rdar://105133434
* begin_cow_mutation
* global_value
* strong_retain and strong_release
So far, those simplifications did only run in SILCombine. Now they are also considered in the swift Simplification pass.
If a `debug_step` has the same debug location as a previous or succeeding instruction it is removed.
It's just important that there is at least one instruction for a certain debug location so that single stepping on that location will work.
This instruction can be inserted by Onone optimizations as a replacement for deleted instructions to
ensure that it's possible to single step on its location.
The path components may not be related to the current value in case mismatching types are visited, e.g. different concrete types of an existential.
This can lead to mismatching operand numbers for struct and tuple instructions.
rdar://104435056
* for testing: add the option `-simplify-instruction=<instruction-name>` to only run simplification passes for that instruction type
* on the swift side, add `Options.enableSimplification`
