> On Dec 18, 2015, at 10:29 AM, Joe Groff <jgr...@apple.com> wrote: >> On Dec 17, 2015, at 3:43 PM, John McCall <rjmcc...@apple.com> wrote: >> >>> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev <swift-dev@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. _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
