[swift-dev] Value-result ABI for small trivial inouts

[John McCall]

> On Dec 18, 2015, at 10:29 AM, Joe Groff <jgroff at apple.com> wrote:
>> On Dec 17, 2015, at 3:43 PM, John McCall <rjmccall at apple.com> wrote:
>> 
>>> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
>>> We currently always pass inout parameters indirectly, but it seems to me that for inout parameters that are of small trivial types like Int or CGSize, a value-result calling convention might always be preferable, and we might want to codify that in the stable ABI. Values of these types are likely to be SSAed, and the indirect convention forces memory traffic that would otherwise be unnecessary. On ARMv7 and ARM64, the argument and return register sets are the same, so a value-result convention is likely to be able to compile down to in-place operations on those registers, so it's a potential code size win too.
>>> 
>>> (Value-result is not a clear win for nontrivial types, since it forces a load and retain onto the outermost caller that inouts a value in memory, since we can't invalidate the memory during the inout call. The extra retain would potentially defeat COW optimization. We have primitives like `isUniquelyReferenced` that depend on mutable references being in memory too.)
>> 
>> IIRC, the mutation model does try to make stronger promises about updates to stored variables and properties; this would interfere with that.
> 
> Maybe. I know we try to make stronger promises about partial object updates, so things like swap(&a.x, &a.y) or swap(&a[0], &a[1]) work with stored `x` and `y` or addressed subscripts, but we're still pretty cavalier about when the updates get published. A capture or reabstraction can implicitly introduce writebacks on the callee side even if the caller passed in a property they know to be stored.

True.

John.