The reason why is that we want to distinguish inbetween SILFunction's that are
marked as unspecified by SILGen and those that are parsed from textual SIL that
do not have any specified isolation. This will make it easier to write nice
FileCheck tests against SILGen output on what is the inferred isolation for
various items.
NFCI.
If a single native value is bridged multiple times, it cannot be
consumed without other changes. One option would be to copy it. The
other option is taken here: sink the destroy of the native value to
after the apply and have the outlined function take the value
guaranteed.
rdar://134198292
I thought `reverse(silFn)` would do a post-order walk, but I was wrong.
This patch cuts the number of iterations to propagate coldness from
3-4 down to 2 in a few of the simple regression test cases. At least on
macOS (as the stdlib can vary per platform).
Mangling this information for future directions like component lifetimes
becomes complex and the current mangling scheme isn't scalable anyway.
Deleting this support for now.
Back off treating local lets of tuple type as "initializable", expanding
on the narrow carve-out from #74133. Without this, we would reject local
lets of tuple type that are initialized piecemeal.
Fixes rdar://135028163.
This PR ensures library-evolution is enabled for Package CMO; without it,
it previously fell back to regular CMO, which caused mismatching serialization
attributes if importing another module that had Package CMO enbaled, causing
an assert fail for loadable types.
Resolves rdar://135308288
The old analysis pass doesn't take into account profile data, nor does
it consider post-dominance. It primarily dealt with _fastPath/_slowPath.
A block that is dominated by a cold block is itself cold. That's true
whether it's forwards or backwards dominance.
We can also consider a call to any `Never` returning function as a
cold-exit, though the block(s) leading up to that call may be executed
frequently because of concurrency. For now, I'm ignoring the concurrency
case and assuming it's cold. To make use of this "no return" prediction,
use the `-enable-noreturn-prediction` flag, which is currently off by
default.
No update is needed for the values they produce. This pass should
really be refactored not to crash on instructions that aren't explicitly
listed or at least not to compile if not every instruction is listed.
rdar://133779160
Usually there _must_ be a read from a consuming in-argument, because the function has to consume the argument.
But in the special case if all control paths end up in an `unreachable`, the consuming read might have been dead-code eliminated.
Therefore make sure to add the read-effect in any case. Otherwise it can result in memory lifetime failures at a call site.
fixes a memory lifetime failure
rdar://134881045
Unknown uses of raw pointers should not result in bailing out when an
address is lexical--the destroy of the address will already not be
hoisted over any instructions which may access pointers. If the address
is not lexical however (such as any address when lexical lifetimes are
disabled), that rationale does not apply, so unknown uses of raw
pointers must cause hoisting to bail.
rdar://133969821
If there is no read from an indirect argument, this argument has to be dropped.
At the call site the store to the argument's memory location could have been removed (based on the callee's memory effects).
Therefore, converting such an unused indirect argument to a direct argument, would load an uninitialized value at the call site.
This would lead to verifier errors and in worst case to a miscompile because IRGen can implicitly use dead arguments, e.g. for getting the type of a class reference.
Instead of adding a "flag" (`m` in `...Tgm5`) make it more generic to allow to drop any unused argument.
Add all dropped arguments with a `t<n-1>` (where `<n-1>` is empty for n === 0). For example `...Ttt2g5`.
Do this even if the function then contains references to other functions with wrong linkage. Instead fix the linkage later.
Fixes a false error in embedded swift.
rdar://134352676
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
