Are there any more concerns here? The thread has seemed to die down and I would like to begin upstreaming this code if possible.
Michael > On Dec 6, 2016, at 2:23 PM, John McCall <rjmcc...@apple.com> wrote: > >> On Dec 6, 2016, at 11:35 AM, Joe Groff <jgr...@apple.com >> <mailto:jgr...@apple.com>> wrote: >>> On Dec 6, 2016, at 11:29 AM, John McCall <rjmcc...@apple.com >>> <mailto:rjmcc...@apple.com>> wrote: >>> >>>> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev <swift-dev@swift.org >>>> <mailto:swift-dev@swift.org>> wrote: >>>>> On Dec 5, 2016, at 4:24 PM, Michael Gottesman via swift-dev >>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>>> >>>>> Hello everyone! >>>>> >>>>> 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. >>>>> >>>>> A html version of the proposal: >>>>> >>>>> https://gottesmm.github.io/proposals/sil-ownership-value-ssa-operations.html >>>>> >>>>> <https://gottesmm.github.io/proposals/sil-ownership-value-ssa-operations.html> >>>>> >>>>> And inline: >>>>> >>>>> ---- >>>>> >>>>> # Summary >>>>> >>>>> This document proposes the addition of the following new SIL instructions: >>>>> >>>>> 1. `store_borrow` >>>>> 2. `begin_borrow` >>>>> >>>>> These enable the expression of the following operations in Semantic SIL: >>>>> >>>>> 1. Passing an `@guaranteed` value to an `@in_guaranteed` argument without >>>>> performing a copy. (`store_borrow`) >>>>> 2. Copying a field from an `@owned` aggregate without consuming or >>>>> copying the entire >>>>> aggregate. (`begin_borrow`) >>>>> 3. Passing an `@owned` value as an `@guaranteed` argument parameter. >>>>> >>>>> # Definitions >>>>> >>>>> ## store_borrow >>>>> >>>>> Define `store_borrow` as: >>>>> >>>>> store_borrow %x to %y : $*T >>>>> ... >>>>> end_borrow %y from %x : $*T, $T >>>>> >>>>> => >>>>> >>>>> store %x to %y >>>>> >>>>> `store_borrow` is needed to convert `@guaranteed` values to >>>>> `@in_guaranteed` >>>>> arguments. Without a `store_borrow`, this can only be expressed via an >>>>> inefficient `copy_value` + `store` + `load` + `destroy_value` sequence: >>>>> >>>>> sil @g : $@convention(thin) (@in_guaranteed Foo) -> () >>>>> >>>>> sil @f : $@convention(thin) (@guaranteed Foo) -> () { >>>>> bb0(%0 : $Foo): >>>>> %1 = function_ref @g : $@convention(thin) (@in_guaranteed Foo) -> () >>>>> %2 = alloc_stack $Foo >>>>> %3 = copy_value %0 : $Foo >>>>> store %3 to [init] %2 : $Foo >>>>> apply %1(%2) : $@convention(thin) (@in_guaranteed Foo) -> () >>>>> %4 = load [take] %2 : $*Foo >>>>> destroy_value %4 : $Foo >>>>> dealloc_stack %2 : $Foo >>>>> ... >>>>> } >>>>> >>>>> `store_borrow` allows us to express this in a more efficient and >>>>> expressive SIL: >>>>> >>>>> sil @f : $@convention(thin) (@guaranteed Foo) -> () { >>>>> bb0(%0 : $Foo): >>>>> %1 = function_ref @g : $@convention(thin) (@in_guaranteed Foo) -> () >>>>> %2 = alloc_stack $Foo >>>>> store_borrow %0 to %2 : $*T >>>>> apply %1(%2) : $@convention(thin) (@in_guaranteed Foo) -> () >>>>> end_borrow %2 from %0 : $*T, $T >>>>> dealloc_stack %2 : $Foo >>>>> ... >>>>> } >>>>> >>>>> **NOTE** Once `@in_guaranteed` arguments become passed as values, >>>>> `store_borrow` >>>>> will no longer be necessary. >>>>> >>>>> ## begin_borrow >>>>> >>>>> Define a `begin_borrow` instruction as: >>>>> >>>>> %borrowed_x = begin_borrow %x : $T >>>>> %borrow_x_field = struct_extract %borrowed_x : $T, #T.field >>>>> apply %f(%borrowed_x) : $@convention(thin) (@guaranteed T) -> () >>>>> end_borrow %borrowed_x from %x : $T, $T >>>>> >>>>> => >>>>> >>>>> %x_field = struct_extract %x : $T, #T.field >>>>> apply %f(%x_field) : $@convention(thin) (@guaranteed T) -> () >>>>> >>>>> A `begin_borrow` instruction explicitly converts an `@owned` value to a >>>>> `@guaranteed` value. The result of the `begin_borrow` is paired with an >>>>> `end_borrow` instruction that explicitly represents the end scope of the >>>>> `begin_borrow`. >>>>> >>>>> `begin_borrow` also allows for the explicit borrowing of an `@owned` >>>>> value for >>>>> the purpose of passing the value off to an `@guaranteed` parameter. >>>>> >>>>> *NOTE* Alternatively, we could make it so that *_extract operations >>>>> started >>>>> borrow scopes, but this would make SIL less explicit from an ownership >>>>> perspective since one wouldn't be able to visually identify the first >>>>> `struct_extract` in a chain of `struct_extract`. In the case of >>>>> `begin_borrow`, >>>>> there is no question and it is completely explicit. >>>> >>>> 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. >>> >>> I definitely think it should be explicit, as Michael has it. >> >> 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. > > 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. > > It's also quite a bit easier to verify things when there's a simple nesting > property, e.g. > %1 = load_borrow %0 > %2 = struct_element borrow %1, $foo > %3 = blah > end_borrow %2 > end_borrow %1 > as opposed to tracking that uses of %2 implicitly require both %2 and %1 to > have remained borrowed. > > 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. > > 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. > > John.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
