On Oct 11, 2016, at 10:10 AM, Michael Gottesman <mgottes...@apple.com> wrote: >> >If ARC Code Motion wishes to move the ARC semantics of ownership qualified >> >load, store instructions, it must now consider read/write effects. On the >> >other hand, it will be able to now not consider the side-effects of >> >destructors when moving retain/release operations. >> >> Can you elaborate on what you mean by this? Does this mean the ARC >> optimizer has additional freedom somehow to ignore side effects in deinits? >> What grants that ability? > > Sorry for not being clear. > > deinits in ARC are not sequenced with respect to memory operations in normal > control flow, but if ARC performs any code motion, we must ensure that memory > safety is respected. Such semantics are not new. > > The main change here is that previously there were situations where we would > split up the load/retain in a load [copy] operation. Then if the right things > occured, we could cause the object to be deallocated before we use the value > or took full ownership of the value.
Ah, I see what you mean. Got it. > In this case, we would be passing off to useD a deallocated instance of class > D1 which would be undefined behavior. > > So as long as for these load [copy] operations, we move the load/retain fused > together, we can guarantee that an object is produced instantaneously in a > safe way without any worry. > > Was this helpful? Yep, totally. The new approach is much more clear, thanks Michael! -Chris
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
