Optimizer: Rework peephole optimizations to replace existential (archetypes) with concrete types #79674

eeckstein · 2025-02-27T21:12:17Z

Those optimizations were done in SILCombine, but the implementation is very complicated.
This PR starts to de-compose the complex logic into small instruction simplifications.

It also adds the ability to figure out the concrete type of metatype existentials - which was missing in the current implementation in SILCombine.

This lets us optimize code like

func takesA<T: ProtoA>(_ type: T.Type) -> T? {
  // Constant fold this cast when takesA is specialized for a concrete type.
  if let bType = T.self as? ProtoB.Type {
    return createB(bType) as? T
  }
  return nil
}

This PR also contains a lot of Swift SIL infrastructure improvements.
See the commit messages for details.

Fixes an optimization deficiency
rdar://139199849

eeckstein · 2025-02-27T21:13:14Z

@swift-ci test

eeckstein · 2025-02-27T21:13:20Z

@swift-ci benchmark

eeckstein · 2025-02-27T21:13:31Z

@swift-ci apple silicon benchmark

eeckstein · 2025-02-27T21:13:41Z

@swift-ci test source compatibility

slavapestov · 2025-02-27T21:21:53Z

SwiftCompilerSources/Sources/AST/SubstitutionMap.swift

@@ -28,6 +28,15 @@ public struct SubstitutionMap: CustomStringConvertible {
  public init() {
    self.bridged = BridgedSubstitutionMap()
  }
+
+  public init(forGenericSignatureOf functionType: CanonicalType,


This should just take a generic signature and not a generic function type.

We don't have GenericSignature bridged to Swift yet. I can do this in a follow up PR

Never mind, I included it in this PR

atrick · 2025-02-28T07:36:14Z

I haven't looked at the new implementation yet. I'll just repeat the same advice I gave when the original version was checked in. Attempting to pattern match backward starting at the call site is a misguided approach. Normal compilers would do this kind of optimization using forward sparse constant propagation (SCCP), which propagates type information as well as constants.

eeckstein · 2025-02-28T15:33:32Z

Attempting to pattern match backward starting at the call site is a misguided approach.

This is not what's happening here. The peephole optimizations run in SILCombine's worklist loop so information is (also) propagated in forward direction.

And SCCP - well we don't do it in the whole compiler. And especially for this purpose it would be over-engineered. An existential which is conditionally initialized with two different concrete types (and one case is dead, depending on the other type) is really a very esoteric corner case. We need to make sure to be able to optimize the common cases - and we are not there, yet.

atrick · 2025-03-02T17:05:44Z

This is not what's happening here. The peephole optimizations run in SILCombine's worklist loop so information is (also) propagated in forward direction.

Right, from your description it sounded like was your approach. I'm surprised it was possible without new instructions. That's a good approach as long as each individual transform is clearly moving in one direction toward a simpler or canonical form. A big problem with peepholes is that two different optimizations might not agree on the canonical form.

atrick · 2025-03-02T17:14:44Z

And SCCP - well we don't do it in the whole compiler.

Yes, I'm not suggesting doing that instead of this PR. I'm just repeating my advice from a decade ago so it isn't forgotten. It's a simpler way to do specialization vs backward pattern matching and not that difficult, expensive, or complicated. It's similar to how much simpler it is to propagate "borrowed-from" information using forward data flow vs. backward recursion (find-adjacent-phi)

eeckstein · 2025-03-06T07:42:01Z

@swift-ci test

eeckstein · 2025-03-06T07:42:57Z

@swift-ci apple silicon benchmark

eeckstein · 2025-03-06T07:43:32Z

@swift-ci test source compatibility

Check if an operand's instruction has been deleted in `UseList.next()`. This allows to delete an instruction, which has two uses of a value, during use-list iteration.

There is no `isNominal` property in SIL.Type.

* getting the formal source and target types of casts * `isFromVarDecl` and `usesMoveableValueDebugInfo` for AllocStackInst * WitnessMethod APIs * `TryApply.isNonAsync`

The optional C++ type was bridged to a non-optional Swift type. The correct way is to bridged the non-optional C++ type to the non-optional Swift type.

* `createCheckedCastAddrBranch` * `createUnconditionalCheckedCastAddr` * `createDebugValue` * `createWitnessMethod` * `createInitEnumDataAddr`

…ing the conformances in an Array Instead of a ConformanceArray

…ting SILCombine visit function. So far a `SILCombineSimplifiable` could only replace a SILCombine visit implementation. With the `SWIFT_SILCOMBINE_PASS_WITH_LEGACY` (to be used in Passes.def) it's possible to keep an existing C++ implementation and on top of that add a Swift Simplification pass.

…ypes. Replace `unconditional_checked_cast` to an existential metatype with an `init_existential_metatype`, it the source is a conforming type. Note that init_existential_metatype is better than unconditional_checked_cast because it does not need to do any runtime casting.

* factor out common methods of AST Type/CanonicalType into a `TypeProperties` protocol. * add more APIs to AST Type/CanoncialType. * move `MetatypeRepresentation` from SIL.Type to AST.Type and implement it with a swift enum. * let `Builder.createMetatype` get a CanonicalType as instance type, because the instance type must not be a lowered type.

And simplify the implementation of `var Instruction.definedOperands`

…rns a sequence of the specific instruction class and not a sequence of `Instruction`

* `func Instruction.dominatesInSameBlock(_ otherInst: Instruction) -> Bool` * `var Instruction.concreteTypeOfDependentExistentialArchetype`

and add `var Type.invocationGenericSignatureOfFunctionType`

And let it conform to `NoReflectionChildren` to make it's debug dump in lldb nicer

@opend

…y instructions If an apply uses an existential archetype (`@opened("...")`) and the concrete type is known, replace the existential archetype with the concrete type 1. in the apply's substitution map 2. in the arguments, e.g. by inserting address casts For example: ``` %5 = apply %1<@opend("...")>(%2) : <τ_0_0> (τ_0_0) -> () ``` -> ``` %4 = unchecked_addr_cast %2 to $*ConcreteType %5 = apply %1<ConcreteType>(%4) : <τ_0_0> (τ_0_0) -> () ```

…itness_method instructions

@thick

* Reimplement most of the logic in Swift as an Instruction simplification and remove the old code from SILCombine * support more cases of existential archetype replacements: For example: ``` %0 = alloc_stack $any P %1 = init_existential_addr %0, $T use %1 ``` is transformed to ``` %0 = alloc_stack $T use %0 ``` Also, if the alloc_stack is already an opened existential and the concrete type is known, replace it as well: ``` %0 = metatype $@thick T.Type %1 = init_existential_metatype %0, $@thick any P.Type %2 = open_existential_metatype %1 : $@thick any P.Type to $@thick (@opened("X", P) Self).Type ... %3 = alloc_stack $@opened("X", any P) Self use %3 ``` is transformed to ``` ... %3 = alloc_stack $T use %3 ```

Don't get the swift source version string, but the debug dump string

eeckstein · 2025-03-07T15:00:14Z

@swift-ci test

eeckstein requested review from jckarter, hborla, slavapestov and xedin as code owners February 27, 2025 21:12

eeckstein requested review from atrick, meg-gupta and nate-chandler and removed request for xedin and hborla February 27, 2025 21:12

slavapestov reviewed Feb 27, 2025

View reviewed changes

eeckstein force-pushed the simplify-open-existential-metatype branch from acb2617 to 64f6fe2 Compare February 28, 2025 15:05

eeckstein force-pushed the simplify-open-existential-metatype branch from 64f6fe2 to 1f60301 Compare March 6, 2025 07:40

eeckstein added 7 commits March 7, 2025 15:59

SIL: be more tolerant when a user is deleted during use-list iteration.

48db890

Check if an operand's instruction has been deleted in `UseList.next()`. This allows to delete an instruction, which has two uses of a value, during use-list iteration.

Swift AST: add some APIs to Type and CanonicalType

eadfbf6

SIL: fix two comments in Type.swift

8adec32

There is no `isNominal` property in SIL.Type.

Swift SIL: add some Instruction APIs

3105733

* getting the formal source and target types of casts * `isFromVarDecl` and `usesMoveableValueDebugInfo` for AllocStackInst * WitnessMethod APIs * `TryApply.isNonAsync`

SIL: fix bridging of SILDebugVariable

f7466ea

The optional C++ type was bridged to a non-optional Swift type. The correct way is to bridged the non-optional C++ type to the non-optional Swift type.

Swift SIL: add some Builder APIs

db03a55

* `createCheckedCastAddrBranch` * `createUnconditionalCheckedCastAddr` * `createDebugValue` * `createWitnessMethod` * `createInitEnumDataAddr`

SIL Builder: make createInitExistentialMetatype more usable by pass…

4595d5d

…ing the conformances in an Array Instead of a ConformanceArray

eeckstein added 15 commits March 7, 2025 15:59

Fix a comment about SILCombine "passes" in Passes.def

de841fd

SIL: add var Instruction.typeDependentOperands

7bbd9a9

And simplify the implementation of `var Instruction.definedOperands`

SIL: add an overload of Sequence<Operand>.users(ofType:) which retu…

213da24

…rns a sequence of the specific instruction class and not a sequence of `Instruction`

Optimizer: add two small utilities for instructions

5016e35

* `func Instruction.dominatesInSameBlock(_ otherInst: Instruction) -> Bool` * `var Instruction.concreteTypeOfDependentExistentialArchetype`

SIL: add var FullApplySite.singleDirectErrorResult

0f55220

Swift AST: add GenericSignature

67925ea

and add `var Type.invocationGenericSignatureOfFunctionType`

Swift AST: add an initializer to SubstitutionMap

431401c

And let it conform to `NoReflectionChildren` to make it's debug dump in lldb nicer

Swift SIL: make isLegalFormalType available in AST.Type

77dab77

SILOptimizer: replace existential archetypes with concrete types in w…

5572c83

…itness_method instructions

Swift AST: Fix debug description of Type

Loading
Loading status checks…

26c7310

Don't get the swift source version string, but the debug dump string

eeckstein force-pushed the simplify-open-existential-metatype branch from 1f60301 to 26c7310 Compare March 7, 2025 14:59

eeckstein requested a review from ktoso as a code owner March 7, 2025 14:59

eeckstein merged commit 737b5ec into swiftlang:main Mar 10, 2025
5 checks passed

eeckstein deleted the simplify-open-existential-metatype branch March 10, 2025 07:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Optimizer: Rework peephole optimizations to replace existential (archetypes) with concrete types #79674

Optimizer: Rework peephole optimizations to replace existential (archetypes) with concrete types #79674

eeckstein commented Feb 27, 2025

eeckstein commented Feb 27, 2025

eeckstein commented Feb 27, 2025

eeckstein commented Feb 27, 2025

eeckstein commented Feb 27, 2025

slavapestov Feb 27, 2025

eeckstein Feb 27, 2025

eeckstein Feb 28, 2025 •

edited

Loading

atrick commented Feb 28, 2025

eeckstein commented Feb 28, 2025 •

edited

Loading

atrick commented Mar 2, 2025

atrick commented Mar 2, 2025

eeckstein commented Mar 6, 2025

eeckstein commented Mar 6, 2025

eeckstein commented Mar 6, 2025

eeckstein commented Mar 7, 2025

Optimizer: Rework peephole optimizations to replace existential (archetypes) with concrete types #79674

Optimizer: Rework peephole optimizations to replace existential (archetypes) with concrete types #79674

Conversation

eeckstein commented Feb 27, 2025

eeckstein commented Feb 27, 2025

eeckstein commented Feb 27, 2025

eeckstein commented Feb 27, 2025

eeckstein commented Feb 27, 2025

slavapestov Feb 27, 2025

Choose a reason for hiding this comment

eeckstein Feb 27, 2025

Choose a reason for hiding this comment

eeckstein Feb 28, 2025 • edited Loading

Choose a reason for hiding this comment

atrick commented Feb 28, 2025

eeckstein commented Feb 28, 2025 • edited Loading

atrick commented Mar 2, 2025

atrick commented Mar 2, 2025

eeckstein commented Mar 6, 2025

eeckstein commented Mar 6, 2025

eeckstein commented Mar 6, 2025

eeckstein commented Mar 7, 2025

eeckstein Feb 28, 2025 •

edited

Loading

eeckstein commented Feb 28, 2025 •

edited

Loading