> 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.)
This makes me wonder, are stores to inouts ever visible if a function throws? Also, it seems you’ll need to re-abstract when passing (inout Int) -> () as (inout T) -> (), does this fit in with the existing mechanisms? > > -Joe > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
