> 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. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
