> On Oct 5, 2016, at 4:48 PM, Michael Gottesman <mgottes...@apple.com> wrote: >> On Oct 5, 2016, at 4:40 PM, Michael Gottesman via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >>> >>> On Oct 4, 2016, at 1:04 PM, John McCall <rjmcc...@apple.com >>> <mailto:rjmcc...@apple.com>> wrote: >>> >>>> >>>> On Sep 30, 2016, at 11:54 PM, Michael Gottesman via swift-dev >>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>> >>>> The document attached below contains the first "Semantic ARC" mini >>>> proposal: the High Level ARC Memory Operations Proposal. >>>> >>>> An html rendered version of this markdown document is available at the >>>> following URL: >>>> >>>> https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html >>>> <https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html> >>>> >>>> ---- >>>> >>>> # Summary >>>> >>>> This document proposes: >>>> >>>> 1. adding the `load_strong`, `store_strong` instructions to SIL. These can >>>> only >>>> be used with memory locations of `non-trivial` type. >>> >>> I would really like to avoid using the word "strong" here. Under the >>> current proposal, these instructions will be usable with arbitrary >>> non-trivial types, not just primitive class references. Even if you think >>> of an aggregate that happens to contain one or more strong references as >>> some sort of aggregate strong reference (which is questionable but not >>> completely absurd), we already have loadable non-strong class references >>> that this operation would be usable with, like native unowned references. >>> "load_strong %0 : $*@sil_unowned T" as an operation yielding a scalar >>> "@sil_unowned T" is ridiculous, and it will only get more ridiculous when >>> we eventually allow this operation to work with types that are currently >>> address-only, like weak references. >>> >>> Brainstorming: >>> >>> Something like load_copy and store_copy would be a bit unfortunate, since >>> store_copy doesn't actually copy the source operand and we want to have a >>> load_copy [take]. >>> >>> load_value and store_value seem excessively generic. It's not like >>> non-trivial types aren't values. >>> >>> One question that comes to mind: do we actually need new instructions here >>> other than for staging purposes? We don't actually need new instructions >>> for pseudo-linear SIL to work; we just need to say that we only enforce >>> pseudo-linearity for non-trivial types. >>> >>> If we just want the instruction to be explicit about ownership so that we >>> can easily distinguish these cases, we can make the rule always explicit, >>> e.g.: >>> load [take] %0 : $*MyClass >>> load [copy] %0 : $*MyClass >>> load [trivial] %0 : $*Int >>> >>> store %0 to [initialization] %1 : $*MyClass >>> store %0 to [assignment] %1 : $*MyClass >>> store %0 to [trivial] %1 : $*Int >>> >>> John. >> >> The reason why I originally suggested to go the load_strong route is that we >> already have load_weak, load_unowned instructions. If I could add a >> load_strong instruction, then it would make sense to assign an engineer to >> do a pass over all 3 of these instructions and combine them into 1 load >> instruction. That is, first transform into a form amenable for >> canonicalization and then canonicalize all at once. >> >> As you pointed out, both load_unowned and load_weak involve representation >> changes in type (for instance the change of weak pointers to Optional<T>). >> Such a change would be against the "spirit" of a load instruction to perform >> such representation changes versus ownership changes. >> >> In terms of the properties that we actually want here, what is important is >> that we can verify that no non-trivially typed values are loaded in an >> unsafe unowned manner. That can be done also with ownership flags on >> load/store. >> >> Does this sound reasonable: >> >> 1. We introduce two enums that define memory ownership changes, one for load >> and one for store. Both of these enums will contain a [trivial] ownership. >> 2. We enforce in the verifier that non-trivial types must have a non-trivial >> ownership modifier on any memory operations that they are involved in. > > Sorry for not being explicit. I will not add new instructions, just > modifiers. Assuming that this is agreeable to you, I am going to prepare a > quick additional version of the proposal document.
That sounds great, thanks. John.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
