> On Oct 12, 2016, at 11:19 AM, Alexis via swift-dev <email@example.com>
> 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
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
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
>> On Oct 11, 2016, at 7:48 PM, Erik Eckstein via swift-dev
>> <firstname.lastname@example.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.
>> If you have any comments, please let me know.
>> swift-dev mailing list
> swift-dev mailing list
swift-dev mailing list