If somebody called `demangleType` or `demangleSymbol` using a demangler that was already
in the middle of demangling a string, then the state for the new demangler would clobber the old
demangler. This manifested in rdar://problem/50380275 because, as part of demangling a
string with a symbolic reference to a private type's context, we would demangle the debug string
for the referenced context using the same demangler. If there were additional operators in the
original string after the symbolic reference, these never got demangled because the demangler
was now in the state of having completed demangling the other string, so we would drop nesting,
and incorrectly report field types of, for instance, `Array<PrivateStruct>` or
`(PrivateStruct, OtherStruct)` as just being `PrivateStruct`.
This is a likely situation to be in, especially now that `Demangler` objects also serve as
arena allocators for their demangled nodes, so change the top-level demangler entry points
to use an RAII object to push and pop the existing state instead of unilaterally clobbering
the existing state.
Specifically:
1. I removed an extra defensive copy that we put in place some time ago that
isn't really warranted. We know that we have an @owned value, so can safely just
pass the value as a @guaranteed parameter. This also eliminates an ownership
error that would occur due to my not having updated this code for ownership in
tree.
2. I also ensured that if we are performing a loadable address bridging cast ->
value bridging cast that we store the loadable value back into memory after we
perform the cast. Otherwise, it appears to leak to the ownership verifier.
I also centralized the non-ownership tests for this into one place
(const_fold_objc_bridge.sil => constant_propagation_objc.sil).
[Const Evaluator] Make compile-time constant evaluator correctly handle s_to_s_checked_trunc_IntLiteral_IntNN where the bit width of the source symbolic value (an APInt) could be smaller than the destination bits
Specifically, in this part of the cast optimizer we are trying to optimize casts
that can be done in two parts. As an example consider: NSObject ->
Array<Any>. In this case, we first cast from NSObject -> NSArray and then try to
conditionally bridge to Array<Any> from NSArray.
The problem is we did not destroy the NSObject correctly if the first cast
failed. I couldn't figure out how to create an actual swift test case that
produces this problem since we are pretty conservative about triggering this
code path. But in SIL it is pretty easy and in ossa, we trigger the ownership
verifier.
This is another victory for the ownership verifier!
rdar://51753580
This was exposed by test/SILOptimizer/diagnostic_constant_propagation.swift. It
isn't a pattern in the mandatory inlining tests. I added some tests for it.
Add `llvm_unreachable` to mark covered switches which MSVC does not
analyze correctly and believes that there exists a path through the
function without a return value.
With the advent of dynamic_function_ref the actual callee of such a ref
my vary. Optimizations should not assume to know the content of a
function referenced by dynamic_function_ref. Introduce
getReferencedFunctionOrNull which will return null for such function
refs. And getInitialReferencedFunction to return the referenced
function.
Use as appropriate.
rdar://50959798
The specific problem here is that we are setting the insertion point of a
SILBuilder and not unsetting it. I fixed the problem by creating a separate
builder so the original builder stays put.
I originally came across this in my work on moving ownership stripping after the
diagnostic passes. This patch fixes it without my other changes to ease
cherry-picking to 5.1.
I also added more test coverage by expanding the test case to also handle
copy_on_success and take_always.
rdar://51093557
This is needed now that const expr handles string operations/etc. There aren't
tests for this now since I would need to stub out the stdlib. But these are
pretty simple changes overall, I do not expect any problems, and I plan on
enabling this relatively soon.
The specific case where this happened here is:
```
// Worklist = [
%0 = struct $Int (...)
%1 = $Klass
%2 = tuple (%0, %1)
(%3, %4) = destructure_tuple %2
store %3 to [trivial] %3stack
store %4 to [init] %4stack
```
What would happen is we would visit the destructure_tuple, replace %3 with %0
but fail to propagate %4:
```
%0 = struct $Int (...)
%1 = $Klass
%2 = tuple (%0, %1)
(%3, %4) = destructure_tuple %2
store %0 to [trivial] %3stack
store %4 to [init] %4stack
```
This then causes the tuple to be added to the worklist. When we visit the tuple,
we see that we have a destructure_tuple that is a user of the tuple, we see that
it still has that Struct as a user despite us having constant propagated that
component of the tuple. This then causes us to add the struct back to the
worklist despite that tuple component having no uses. Then when we visit the
struct. Which causes us to visit the tuple, etc.
rdar://49947112
This is the complement to load canonicalization. Although store
canonicalization is not required before diagnostics, it should be
defined in the same utility.
The recursivelyDeleteTriviallyDeadInstructions utility takes a
callBack to be called for every deleted instruction. However, it
wasn't passing this callBack to eraseFromParentWithdebugInsts. The
callback was used to update an iterator in some cases, so not calling
it resulted in iterator invalidation.
Doing this also cleans up the both APIs:
recursivelyDeleteTriviallyDeadInstructions and eraseFromParentWithdebugInsts.
This adds support to the load->struct_extract canonicalization for
nontrivial element types which look like:
load [copy]
borrow
struct_extract
...uses...
end_borrow
destroy
