> On Dec 9, 2016, at 4:17 PM, Michael Gottesman <mgottes...@apple.com> wrote: > > Are there any more concerns here? The thread has seemed to die down and I > would like to begin upstreaming this code if possible.
No, I agree with John's points. Your design sounds good. -Joe > 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> wrote: >>>> On Dec 6, 2016, at 11:29 AM, John McCall <rjmcc...@apple.com> wrote: >>>> >>>>> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev >>>>> <swift-dev@swift.org> wrote: >>>>>> On Dec 5, 2016, at 4:24 PM, Michael Gottesman via swift-dev >>>>>> <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 >>>>>> >>>>>> 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
