> On Oct 11, 2016, at 10:10 AM, Joe Groff <jgr...@apple.com> wrote: > > >> On Oct 10, 2016, at 6:58 PM, Andrew Trick <atr...@apple.com> wrote: >> >> >>> On Oct 10, 2016, at 6:23 PM, Joe Groff <jgr...@apple.com> wrote: >>> >>> >>>> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev >>>> <swift-dev@swift.org> wrote: >>>> ** World 1: SSA @inout >>>> >>>> Projecting an element produces a new SILValue. Does this SILValue have >>>> it's own ownership associated with it's lifetime, or is it derived >>>> from it's parent object by looking through projections? >>>> >>>> Either way, projecting any subelement requires reconstructing the >>>> entire aggregate in SIL, through all nesting levels. This will >>>> generate a massive amount of SILValues. Superficially they all need >>>> their own storage. >>>> >>>> [We could claim that projections don't need storage, but that only >>>> solves one side of the problem.] >>>> >>>> [I argue that this actually obscures the producer/consumer >>>> relationship, which is the opposite of the intention of moving to >>>> SSA. Projecting subelements for mutation fundamentally doesn't make >>>> sense. It does make sense to borrow a subelement (not for >>>> mutation). It also makes sense to project a mutable storage >>>> location. The natural way to project a storage location is by >>>> projecting an address...] >>> >>> I think there's a size threshold at which SSA @inout is manageable, and >>> might lead to overall better register-oriented code, if the aggregates can >>> be exploded into a small number of individual values. The cost of >>> reconstructing the aggregate could be mitigated somewhat by introducing >>> 'insert' instructions for aggregates to pair with the projection >>> instructions, similar to how LLVM has insert/extractelement. "%x = >>> project_value %y.field; %x' = transform(%x); %y' = insert %y.field, %x" >>> isn't too terrible compared to the address-oriented formulation. Tracking >>> ownership state through projections and insertions might tricky; haven't >>> thought about that aspect. >>> >>> -Joe >> >> We would have to make sure SROA+mem2reg could still kick in. If that >> happens, I don’t think we need to worry about inout ownership semantics >> anymore. A struct_extract is then essentially a borrow. It’s parent’s >> lifetime needs to be guaranteed, but I don’t know if the subobject needs >> explicit scoping in SIL since there’s no inout scopes to worry about and >> nothing for the runtime to do when the scope ends . >> >> (Incidentally, this would never happen to a CoW type that has a uniqueness >> check—to mutate a CoW type, it’s value needs to be in memory). > > Does a uniqueness check still need to be associated with a memory location > once we associate ownership with SSA values? It seems to me like it wouldn't > necessarily need to be. One thing I'd like us to work toward is being able to > reliably apply uniqueness checks to rvalues, so that code in a "pure > functional" style gets the same optimization benefits as code that explicitly > uses inouts. > > -Joe
We could have an is_unique instruction that returns a “new” reference to storage. But our model for CoW data types relies mutating methods so I don't really know what you have in mind. -Andy _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
