On Jan 24, 2017, at 10:58 PM, Andrew Trick <atr...@apple.com> wrote: > > That would come about when the program wants to use the same lvalue for > multiple real values. I don't expect many problems with simple opaque types. > The only way to mutate them is either passing them @inout or returning them > @out. We could introduce a copy by sinking a use below one of these calls. > But the uses are also likely to be calls. > > It could happen. The typically annoying case with copy coalescing in general > is induction variables that are both modified in the loop and live out of the > loop. I wasn't even able to force a scenario like this with Swift opaque > values that didn't already generate a copy up front.
Ok, I’m a bit concerned about it, but not strongly enough to try to obstruct this architectural change (which, again, seems like totally the right thing to do). I’m ok with just waiting and seeing, particularly given that other constraints (lack of ability to analyze the generic ops) may prevent the bad thing from happening. > There's definitely an issue with all the temporaries needed to inject opaque > values into aggregates. Address lowering needs to be smart about this, but I > have a straightforward storage allocation algortihm in mind that should take > care of the expected cases. I'm anxious to try out a prototype and get some > data. I’d really love to see new ideas on how to change our modeling of this. The injection model is nice in a lot of ways, but seems overly general and has introduced a lot of complexity in the past. -Chris _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
