With the nice optimization of changing default ownership of func parameters from "owned" to "guaranteed", we have a few questions related to the calling conventions and managing retain/release instructions.
For a function
foo(x: SomeClass)that we defined, is there a Swift level annotation (e.g. attribute) that we can use to make x @owned instead of @guaranteed?
SomeClass is a class that we defined. Is there a way to guarantee that a SomeClass-typed value is always consumed at +0, and never +1? It seems no, because for special methods like initializer and setter, params are taken as @owned (https://github.com/apple/swift/blob/f65000ae57ddc5f5fc20fa8d31c9c1c6f771d8e2/lib/SIL/SILFunctionType.cpp#L1146), but I'd like to confirm on this point.
Is there a SIL verifier pass that verifies for a given function
foo(), for each param
vof it, the refcount bias of
vat the exit of
foo()is the same, across all control flow paths? Furthermore, it seems w can verify that value is -1 if
vas a param is taken at +1, or 0 if taken at +0. This question also applies to local values in
For more context, we have a compiler pass (in Swift for Tensorflow project) that moves around or deletes SIL code related to SomeClass values local to a function (SomeClass is Tensor in our case), and thus need to redo refcount (retain/release) balance.
Regarding #1, when we downstream the default ownership change from master (this commit) to our branch, we can use such an annotation to stabilize our existing code.
Regarding #2: For any Tensor-typed value
v (it's local to a SIL function), we know it's created at +1; if we can guarantee that all uses of
v take it at +0, then we can be free to move or delete any such uses, as long as the final
strong_release v is kept.
#3 would in general be useful when we generate or delete SIL code in the compiler.