> On Oct 7, 2016, at 9:25 PM, Andrew Trick <atr...@apple.com> wrote: > > >> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >>> I wonder whether it might make more sense for load [borrow] to be a >>> different instruction. >>> There's a couple reasons for that first. The first is that it's the only >>> load which introduces >>> a scope, which is a really big difference structurally. The second is that >>> it's the only load >>> which returns a non-owned value, which will be a typing difference when we >>> record >>> ownership in the type system. >> >> I am fine with a load_borrow. If this is the only change left that you want >> can I just send out a proposal with that small change and start >> implementing. I am nervous about perfection being the enemy of the good (and >> I want to start implementing this weekend if possible *evil smile*). > > There’s a lot in the proposal that makes sense to discuss for completeness > but isn’t motivated by a particular need. Please separate functionality. We > only need load [copy] at first right? When do those need to be promoted to > load_borrow?
These are needed for the ARC optimizer to eliminate retain, release operations, i.e. a: %0 = load [copy] %x_ptr destroy_value %1 => %0 = load [borrow] %x_ptr borrow_end(%0, %x_ptr) These constructs will be needed by engineers to update passes like ARC. By implementing such modifiers now, we can begin to implement support in the various passes for these new instructions via sil-opt/etc in parallel to other semantic ARC work. > load [trivial] is an optimization, so that should follow a functionally > complete implementation. Yes you are correct that given that we are exploding the load [copy] in the eliminator, the trivial load is not *strictly* needed. But as soon as we start upgrading passes, we are going to want this. Again assuming that parallel work can be done, it makes sense to set the stage for optimizer work that will occur in parallel to further semantic ARC work. > load [take] should definitely not exist until there’s some motivation. If you look at the frontend, there are places where the frontend wants to emit a take. Unless we are willing to use unqualified loads for those cases (which we can not if we are trying to prove that no unqualified loads are emitted by the frontend), then we must have a load [take]. Did I provide the motivation that you requested? Michael > > -Andy
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
