Eliminate the redundant instruction pair
```
%t = tuple (%0, %1, %2)
(%3, %4, %5) = destructure_tuple %t
```
and replace the results %3, %4, %5 with %0, %1, %2, respectively.
The same for structs.
* Check if the address in question is even visible from outside the function
* Return the memory effects of the called function
Also, add a new API `Instruction.memoryEffects`, which is internally used by `mayReadFromMemory` et al.
This reverts commit e9dedf3c27.
The revert is required as foreign reference types are available for SwiftStdlib 5.8 and above, but the Swift compiler
sources back deploy to older stdlibs as well.
This is in preparation for wiring up debug info support for noncopyable
values. Originally this flag name made sense since it was set when we performed
consume operator checking. Now I am going to use it for noncopyable types as
well. I think the new name uses_moveable_value_debuginfo actually describes what
the flag is supposed to do, tell IRGen that the value may be moved since it
needs to use moveable value debug info emission.
A type (mostly classes) can be attributed with `@_semantics("arc.immortal")`.
ARC operations on values of such types are eliminated.
This is useful for the bridged SIL objects in the swift compiler sources.
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
`add_custom_target_command` has a note in its documentation that ask for
all the `COMMAND` arguments to immediately follow the first argument, or
the function will misbehave.
In the two cases below, the `COMMAND` arguments were after the `OUTPUT`
multivalue, and ended by mistake inside the `OUTPUT` parameter. This
kinda works because CMake will interpolate those back, but causes
problems for dependency resolution, marking many targets as dirty. When
one of those targets is dependent by the compiler, this can create
a huge cascade rebuild.
Fix the two cases I found where `add_custom_target_command` was used
incorrectly. This removes cascade rebuilds in my working directory, and
hope it applies to everybody.
