Skip to content

Instantly share code, notes, and snippets.

SIL Opaque Values

Introduction

A SIL type is either loadable or address-only. A loadable type is one whose object size and layout can be determined by the compiler and whose values are not "pinned" to a memory address. Types are most commonly address-only because their layout is opaque by abstraction. Generic type parameters are address-only because their concrete type not statically identified. Resilient types are

SE-0184 Part 2 (recomend splitting into a follow-up proposal): Buffer Full vs. Partial Initialization.

Buffer Memory State

struct UnsafeMutableBufferPointer<Element> 
{
    func initialize<S : Sequence>(from: S) -> (S.Iterator, Index) where S.Element == Element

// Amended: Remove the `at` label on all buffer APIs. Only support full initialization/assignment/deinitialization.

SE-0184 Part 1: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

Here I've listed the changes from SE-0184 that have been reviewed by the core team and are no longer considered controversial. Let's call this SE-1084 Part 1. The diff below summarizes SE-1084 Part 1 vs. Swift 4. The core team requests have been incorporated, and are annotated as "Amended" comments. The amendments are minor and almost exclusively revise the original Swift 3 API rather than calling into question anything newly introduced by SE-0184. Consequently, there's no need for those to go back to swift-evolution. The remainder of SE-0184, part 2, will introduce changes to the slice API in conjunction with the buffer API, so does need to go back to swift-evolution as a new proposal.

Analyzing dispatch performance

When it comes to resilient performance we need to prioritize future flexibility and ABI simplicity over perceived performance advantages. Being able to react to future performance issues that arise with specific apps is far more important than benchmarking. Time not spent implementing complex ABI mechanisms is time that will be spent optimizing more critical performance areas.

It's easy to say we should simply measure performance and let the data

Exclusivity Enforcement in Swift 5

The Swift 5 release enables runtime checking of "Exclusive Access to Memory" by default in Release builds. Previously, these runtime checks were only enabled in Debug builds. In this post, I'll explain what this change means for Swift developers and why it is essential to Swift's strategy for safety and performance.

Background

@atrick
atrick / 2022-variable-lifetime-proposal.md
Last active May 22, 2023 19:02
Swift variable lifetimes

Optimization rules governing the lifetime of Swift variables

Introduction

The combination of automatic reference counting (ARC) and synchronous deinitializers presents a substantial challenge for an optimizing compiler unique to Swift. The Swift 5.7 compiler follows new rules for when optimization is allowed to end the lifetime of variables. The result is more predictable, user-friendly, and performant ARC behavior.

To enforce the new rules, the compiler adopted a new internal representation that tracks the lexical scope of each variable. This involved updating existing optimizations and implementing several new optimizations. Now, all areas of the compiler follow the same, consistent, well-defined rules, making it possible to reason about its behavior for the first time.

The most common programming patterns that depend on extended variable lifetimes are now safe without requiring programmers to explicitly use withExtendedLifetime(). This protec

@atrick
atrick / 2022-04-iterative-reachability.md
Last active May 5, 2022 01:06
Iterative Backward Reachability

Iterative Backward Reachability

This should replace the current non-iterative Reachability. The current non-iterative algorithm would only make sense when uses are post-dominating and we change it to propagate in DFS RPO order. But this algorithm should very seldom need to iterate anyway. So we should probably use it instead.

Input:

  • dominating def

  • uses (gens) - during initialization only

@atrick
atrick / 2022-05-BufferView.md
Last active March 28, 2023 18:07
BufferView Proposal

BufferView Proposal

Introduction

Building Swift system APIs requires a common data type for efficiently viewing contiguous memory as a series of typed elements. This proposal introduces BufferView<T> and MutableBufferView<T> as lowest-common-denominator types that can be used across many low-level APIs without sacrificing safety, efficiency, and generality.

The closest alternative, UnsafeBufferPointer<T>, is not ideal for several reasons:

  • it is ownership unsafe, leading to use-after-free security holes