<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2016, at 3:20 PM, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 7, 2016, at 3:16 PM, Michael Gottesman <<a href="mailto:mgottesman@apple.com" class="">mgottesman@apple.com</a>> wrote:</div><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class="">On Dec 7, 2016, at 2:52 PM, Andrew Trick via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2016, at 2:23 PM, John McCall via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2016, at 11:35 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2016, at 11:29 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">On Dec 5, 2016, at 4:24 PM, Michael Gottesman via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class="">Hello everyone!<br class=""><br class="">This is a proposal for 2 instructions needed to express borrowing via SSA at the SIL level. The need for these were discovered while I was prototyping a SIL ownership verifier.<br class=""><br class="">A html version of the proposal:<br class=""><br class=""><a href="https://gottesmm.github.io/proposals/sil-ownership-value-ssa-operations.html" class="">https://gottesmm.github.io/proposals/sil-ownership-value-ssa-operations.html</a><br class=""><br class="">And inline:<br class=""><br class="">----<br class=""><br class=""># Summary<br class=""><br class="">This document proposes the addition of the following new SIL instructions:<br class=""><br class="">1. `store_borrow`<br class="">2. `begin_borrow`<br class=""><br class="">These enable the expression of the following operations in Semantic SIL:<br class=""><br class="">1. Passing an `@guaranteed` value to an `@in_guaranteed` argument without<br class="">performing a copy. (`store_borrow`)<br class="">2. Copying a field from an `@owned` aggregate without consuming or copying the entire<br class="">aggregate. (`begin_borrow`)<br class="">3. Passing an `@owned` value as an `@guaranteed` argument parameter.<br class=""><br class=""># Definitions<br class=""><br class="">## store_borrow<br class=""><br class="">Define `store_borrow` as:<br class=""><br class=""> store_borrow %x to %y : $*T<br class=""> ...<br class=""> end_borrow %y from %x : $*T, $T<br class=""><br class=""> =><br class=""><br class=""> store %x to %y<br class=""><br class="">`store_borrow` is needed to convert `@guaranteed` values to `@in_guaranteed`<br class="">arguments. Without a `store_borrow`, this can only be expressed via an<br class="">inefficient `copy_value` + `store` + `load` + `destroy_value` sequence:<br class=""><br class=""> sil @g : $@convention(thin) (@in_guaranteed Foo) -> ()<br class=""><br class=""> sil @f : $@convention(thin) (@guaranteed Foo) -> () {<br class=""> bb0(%0 : $Foo):<br class=""> %1 = function_ref @g : $@convention(thin) (@in_guaranteed Foo) -> ()<br class=""> %2 = alloc_stack $Foo<br class=""> %3 = copy_value %0 : $Foo<br class=""> store %3 to [init] %2 : $Foo<br class=""> apply %1(%2) : $@convention(thin) (@in_guaranteed Foo) -> ()<br class=""> %4 = load [take] %2 : $*Foo<br class=""> destroy_value %4 : $Foo<br class=""> dealloc_stack %2 : $Foo<br class=""> ...<br class=""> }<br class=""><br class="">`store_borrow` allows us to express this in a more efficient and expressive SIL:<br class=""><br class=""> sil @f : $@convention(thin) (@guaranteed Foo) -> () {<br class=""> bb0(%0 : $Foo):<br class=""> %1 = function_ref @g : $@convention(thin) (@in_guaranteed Foo) -> ()<br class=""> %2 = alloc_stack $Foo<br class=""> store_borrow %0 to %2 : $*T<br class=""> apply %1(%2) : $@convention(thin) (@in_guaranteed Foo) -> ()<br class=""> end_borrow %2 from %0 : $*T, $T<br class=""> dealloc_stack %2 : $Foo<br class=""> ...<br class=""> }<br class=""><br class="">**NOTE** Once `@in_guaranteed` arguments become passed as values, `store_borrow`<br class="">will no longer be necessary.<br class=""><br class="">## begin_borrow<br class=""><br class="">Define a `begin_borrow` instruction as:<br class=""><br class=""> %borrowed_x = begin_borrow %x : $T<br class=""> %borrow_x_field = struct_extract %borrowed_x : $T, #T.field<br class=""> apply %f(%borrowed_x) : $@convention(thin) (@guaranteed T) -> ()<br class=""> end_borrow %borrowed_x from %x : $T, $T<br class=""><br class=""> =><br class=""><br class=""> %x_field = struct_extract %x : $T, #T.field<br class=""> apply %f(%x_field) : $@convention(thin) (@guaranteed T) -> ()<br class=""><br class="">A `begin_borrow` instruction explicitly converts an `@owned` value to a<br class="">`@guaranteed` value. The result of the `begin_borrow` is paired with an<br class="">`end_borrow` instruction that explicitly represents the end scope of the<br class="">`begin_borrow`.<br class=""><br class="">`begin_borrow` also allows for the explicit borrowing of an `@owned` value for<br class="">the purpose of passing the value off to an `@guaranteed` parameter.<br class=""><br class="">*NOTE* Alternatively, we could make it so that *_extract operations started<br class="">borrow scopes, but this would make SIL less explicit from an ownership<br class="">perspective since one wouldn't be able to visually identify the first<br class="">`struct_extract` in a chain of `struct_extract`. In the case of `begin_borrow`,<br class="">there is no question and it is completely explicit.<br class=""></blockquote><br class="">begin_borrow SGTM. Does end_borrow need to be explicit, or could we leave it implicit and rely on dataflow diagnostics to ensure the borrowed value's lifetime is dominated by the owner's? It seems to me like, even if end_borrow is explicit, we'd want a lifetime-shortening pass to shrinkwrap end_borrows to the precise lifetime of the borrowed value's uses.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">I definitely think it should be explicit, as Michael has it.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></div></blockquote></div><br class=""><div class="">Would you be able to elaborate why? I suppose explicit is a more conservative starting point. It feels to me like making it explicit isn't doing much more than imposing more verification and optimization burden on us, but I'm probably missing something.</div></div></div></blockquote><div class=""><br class=""></div></div>Well, for one, that verification burden isn't unimportant. Under ownership, DI has to enforce things about borrowed values during the lifetime of the borrow. I expect that to apply to values and not just variables. Having lifetimes marked out explicitly should make that much saner.<div class=""><br class=""></div><div class="">It's also quite a bit easier to verify things when there's a simple nesting property, e.g.</div><div class=""> %1 = load_borrow %0</div><div class=""> %2 = struct_element borrow %1, $foo</div><div class=""> %3 = blah</div><div class=""> end_borrow %2</div><div class=""> end_borrow %1</div><div class="">as opposed to tracking that uses of %2 implicitly require both %2 and %1 to have remained borrowed.<br class=""><div class=""><br class=""></div><div class="">For another, it's not obvious that borrowing is a trivial operation. If borrowing can change representations, as it does in Rust and as we might have to do in Swift (for tuples at least, maybe for arrays/strings/whatever), then something needs to represent the lifetime of that representation, and creating it for an opaque T may be non-trivial.</div><div class=""><br class=""></div><div class="">And even if we don't need to generate code normally at begin_borrow / end_borrow points, I can pretty easily imagine that being interesting for extra, sanitizer-style instrumentation.</div></div><div class=""><br class=""></div><div class="">John.</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">Yes, we also need explicit markers for code motion barriers so we don’t need to consider any “use” a potential code barrier.</div><div class=""><br class=""></div><div class="">However, in the most recent proposal I’ve seen, I think we plan to have this instead:</div><div class=""><br class=""></div><div class="">%1 = load_borrow %0 (alternatively begin_borrow)</div><div class="">%2 = struct_extract %1, #field (implied subobject borrow)</div><div class="">%3 = blah %2</div><div class="">end_borrow %1</div><div class=""><br class=""></div><div class="">Note:</div><div class="">- struct_extract only works on a borrowed parent object, so there’s no need for another scope.</div><div class="">- %2 is a dependent value on %1</div><div class="">- You can’t simultaneously shared-borrow one subobject of a value while unique-borrowing another because unique-borrowing requires an address.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Just to be clear, I think what Andy is talking about is whether or not we should suppress borrow sub-scopes.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Whether or not we suppress these subscopes, will not create that much of a difference from the verification point of view since given a borrow of a sub-object from an already borrowed object, we essentially find the load_borrow/begin_borrow, use that to find the sets of end_borrows, and then use that set of end_borrows as part of the verification of the sub-object borrow. The dataflow verifier is implemented to be agnostic to that sort of difference, so it is just a question of how you initialize the dataflow verifier.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">This is a trade-off in between verbosity in the IR and simplicity in the verifier and I am ok with going either way if there are strong feelings in either direction.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Michael</div></div></blockquote></div><br class=""><div class="">I initially thought each borrowed subobject would need its own scope, but I’m not sure it’s necessary and might get out of hand with deep struct nestings.</div></div></div></blockquote><div><br class=""></div></div>I don't think deep struct nestings are that likely, but I agree that it's not necessary to scope a borrowed projection from a borrowed aggregate. That only applies to *non-unique* projections, though.<div class=""><br class=""></div><div class="">John.</div></body></html>