This became necessary after recent function type changes that keep
substituted generic function types abstract even after substitution to
correctly handle automatic opaque result type substitution.
Instead of performing the opaque result type substitution as part of
substituting the generic args the underlying type will now be reified as
part of looking at the parameter/return types which happens as part of
the function convention apis.
rdar://62560867
* Update Devirtualizer's analysis invalidation
castValueToABICompatibleType can change CFG, Devirtualizer uses this api but doesn't check if it modified the cfg
Add DifferentiabilityWitnessDevirtualizer: an optimization pass that
devirtualizes `differentiability_witness_function` instructions into
`function_ref` instructions.
Co-authored-by: Dan Zheng <danielzheng@google.com>
* Handle begin_apply in TempRVO
A tempobj passed to begin_apply instruction and cannot be modified by it
(is guaranteed and doesn't alias with other inout args) can be optimzed
away.
If there is a release of the bridged value in between the bridge call
and the objective-c call we need to account for that and can't just use
a guaranteed convention.
rdar://61911131
The reason why this is important is that if our destroy_value is elided due to
the destroy_value being in a dead end block, we can promote a load [copy] to a
load_borrow even if the load [copy] has a forwarding consuming use outside of a
begin_access region.
I changed every place in SemanticARCOpts that did this sort of thing to use this
pattern instead of just destroys so that no one cargo cults the original pattern
by mistake.
<rdar://problem/61774105>
In a future commit, I am going to build on this to promote load [copy] ->
load_borrow from inout arguments where none of the writes overlap the load
[copy]'s result's lifetime. By committing this separately, I am using the
current pass's logic to validate the change.
When merging many blocks to a single block (in the wrong order), instructions are getting moved over and over again.
This is quadratic and can result in very long compile times for large functions.
To fix this, always move the instruction to smaller block to the larger block.
rdar://problem/56268570
We should not optimize away the copy_addr of a guaranteed parameter of a
non-onstack partial_apply.
This is not a bug currently, because TempRVO checks if the lifetime end
points of the temp object are destroy_addr's in
TempRValueOptPass::checkTempObjectDestroy.
This change makes it explicit on which partial_apply's are ok to
optimize.
rdar://61349083
When inlining many functions in a very large basic block, the splitting of the block at the call sites is quadratic, when traversing in forward order.
Traversing backwards, fixes the problem.
rdar://problem/56268570
