[swift-dev] copy-on-write proposal

[Andrew Trick]

> On Oct 12, 2016, at 11:19 AM, Alexis via swift-dev <swift-dev at swift.org> wrote:
> 
> I’m having trouble figuring something out: is all of this contingent on all of the relevant operations being completely inlined into a single function at the SIL level? Could failing to inline a standard library function lead to performance cliffs? I understand this is generally true of inlining and dead-code elimination; but I’m wondering how this affects the abstractions we expose. Can we know that some things will “always” work, even if parts aren’t inlined?

Well, actually there are two basic approaches that you see within the SIL optimizer. One relies on being able to analyze all instructions between two points in the CFG. That depends on full inlining or deep IPA. The other approach relies on knowledge about aliasing, uniqueness, immutability, and so on reach a conclusion about some opaque region of code.

Some of our optimizations rely on full inlining and conservative analysis, but the more we can capture semantics in SIL, the more we can employ the second approach, which improves the power and robustness of the optimizer.

Erik proposed redundant-load elimination and ARC optimizations that both need to prove the absence of a store to a particular memory location within some region. With the proposed copy-on-write attribute, we can now prove the absence of a store without analyzing any of the instructions in that region. I think this is an good example of the second approach where we can optimize around opaque regions of code. So it’s worth making sure our representation supports that.

It is still true though that enough inlining needs to take place such that we can see a load of the Array storage and access to that storage all in the same function scope.

-Andy

>> On Oct 11, 2016, at 7:48 PM, Erik Eckstein via swift-dev <swift-dev at swift.org> wrote:
>> 
>> This is a proposal for representing copy-on-write buffers in SIL. Actually it’s still a draft for a proposal. It also heavily depends on how we move forward with SIL ownership.
>> <CopyOnWrite.rst>
>> If you have any comments, please let me know.
>> 
>> Erik
>> 
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev