> 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. My larger concern, though, is that I’m not sure that the set of non-inlinable functions taking inouts that are concrete, fixed-size, and trivial is actually worth adding special-case ABI rules for. John. _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
