The function convention for the first argument is not identified as indirect-out.
This lets alias analysis assume that the memory pointed to by argument 0 cannot be written by the called function.
The problem is that subscripting a LazyFilterCollection (with the base index, e.g. `Int`) does not work as expected, because it returns the nth element of the base collection!
The fix is to implement the subscript "manually".
Fixes a mis-compile.
rdar://152160748
This prevents simplification and SILCombine passes to remove (alive) `mark_dependence_addr`.
The instruction is conceptually equivalent to
```
%v = load %addr
%d = mark_dependence %v on %base
store %d to %addr
```
Therefore the address operand has to be defined as writing to the address.
This is a value operation that can work just fine on lowered types,
so there's no need to carry along a formal type. Make the value/address
duality clearer, and enforce it in the verifier.
The lifetime of yielded values always end at the end_apply.
This is required because a yielded address is non-aliasing inside the begin/end_apply scope, but might be aliasing after the end_apply.
For example, if the callee yields an `ref_element_addr` (which is encapsulated in a begin/end_access).
Therefore, even if the callee does not write anything, the effects must be "read" and "write".
Fixes a SIL verifier error
rdar://147601749
If the base value of a mark_dependence is an address, that memory location must be initialized at the mark_dependence.
This requires that the mark_dependence is considered to read from the base address.
Global let-variables are immutable, except in functions which initialize them.
This brings back handling of global let-variables in alias analysis, which was removed in the previous commit.
Although a let-field can never be mutated, a release or consume of the class must be considered as writing to such a field.
This change removes the special handling of let-fields in two places, where they don't belong.
Class fields are handled by ImmutableScope anyway.
Handling of global let-variable is temporarily removed by this commit.
Fixes a miscompile.
rdar://142996449
Checking if an access base is derived from a begin-borrow was too optimistic.
We have to bail for instructions which are not handled by the walker utilities.
Fixes a verifier crash.
rdar://139788357
The main changes are:
*) Rewrite everything in swift. So far, parts of memory-behavior analysis were already implemented in swift. Now everything is done in swift and lives in `AliasAnalysis.swift`. This is a big code simplification.
*) Support many more instructions in the memory-behavior analysis - especially OSSA instructions, like `begin_borrow`, `end_borrow`, `store_borrow`, `load_borrow`. The computation of end_borrow effects is now much more precise. Also, partial_apply is now handled more precisely.
*) Simplify and reduce type-based alias analysis (TBAA). The complexity of the old TBAA comes from old days where the language and SIL didn't have strict aliasing and exclusivity rules (e.g. for inout arguments). Now TBAA is only needed for code using unsafe pointers. The new TBAA handles this - and not more. Note that TBAA for classes is already done in `AccessBase.isDistinct`.
*) Handle aliasing in `begin_access [modify]` scopes. We already supported truly immutable scopes like `begin_access [read]` or `ref_element_addr [immutable]`. For `begin_access [modify]` we know that there are no other reads or writes to the access-address within the scope.
*) Don't cache memory-behavior results. It turned out that the hit-miss rate was pretty bad (~ 1:7). The overhead of the cache lookup took as long as recomputing the memory behavior.
* Allow normal function results of @yield_once coroutines
* Address review comments
* Workaround LLVM coroutine codegen problem: it assumes that unwind path never returns.
This is not true to Swift coroutines as unwind path should end with error result.
This unusual situation can happen if an address is converted to a raw pointer and that pointer is stored to a memory location.
In this case the walkers need to follow load instructions even if the visitor and current projection path don't say so.
Fixes a miscompile
rdar://122805546
This adds SIL-level support and LLVM codegen for normal results of a coroutine.
The main user of this will be autodiff as VJP of a coroutine must be a coroutine itself (in order to produce the yielded result) and return a pullback closure as a normal result.
For now only direct results are supported, but this seems to be enough for autodiff purposes.
Mostly restore the behavior of getMemoryEffectsFn on builtins other than
`once` and `onceWithContext` to before
8a8a895239 but keeping the improvement to
return `Instruction.memoryEffects` in the face of escaping.
So far we unconditionally treated `store [assign]` to have side effects because it destructs the old value.
But we can do better by checking if the address in question actually can escape to a destructor.
* 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.
If the "regular" alias analysis thinks that an instruction may write to an address, check if the instruction is in an immutable scope of V.
That means that even if we don't know anything about the instruction (e.g. a call to an unknown function), we can be sure that it cannot write to the address.
An immutable scope is for example a read-only begin_access/end_access scope.
Another example is a borrow scope of an immutable copy-on-write buffer, for example:
%b = begin_borrow %array_buffer
%addr = ref_element_addr [immutable] %b : $BufferType, #BufferType.someField
* ``begin_access [modify]`` returned MayWrite, but "modify" means, it can be a read as well.
Instead, return MayReadWrite. Only for ``begin_access [init]`` return MayWrite.
This is more or less cosmetic - probably this bug had no real impact on any optimization.
* ``begin_access [deinit]`` needs to return MayReadWrite for the same reason ``destroy_addr`` returns MayReadWrite (see SILInstruction::MemoryBehavior).
Add more relevant instructions to dump in MemBehaviorDumper.
Therefore the -enable-mem-behavior-dump-all option can be removed.
Also mem-behavior-all.sil into mem-behavior.sil, because the sil-opt command lines don't differ anymore.
Even values of trivial type can contain a Builtin.RawPointer, which can be used to read/write from/to.
To compensate for the removed check, enable the escape-analysis check in MemBehavior (as it was before).
This fixes a recently introduced miscompile.
rdar://problem/70220876
1. Do a better alias analysis for "function-local" objects, like alloc_stack and inout parameters
2. Fully support try_apply and begin/end/abort_apply
So far we fully relied on escape analysis. But escape analysis has some shortcomings with SIL address-types.
Therefore, handle two common cases, alloc_stack and inout parameters, with alias analysis.
This gives better results.
The biggest change here is to do a quick check if the address escapes via an address_to_pointer instructions.
This was done some time ago to make it easier to diff large amounts of SIL
output. The problem is that it makes it difficult to know the *true* memory
order that the predecessor list is in which can lead to surprise when working
with SIL and create test cases.
I believe some time after that point we added the notion of "sorted" sil, i.e.
SIL that does not guarantee any relation to the actual memory representation of
the SIL and is meant to ease diffing. This fits nicely with the true intention
of this sort of sorting.
Thus this commit puts sorting PredIDs, UserIDs behind that flag.
