[SIL][Optimizer] eliminate @pack_element types

[elsakeirouz]

Most variadic generic functions contain loops that iterate over the elements of their Pack parameters. Since the types of the pack elements are unknown, witness table methods are used to perform operations on the current pack element in each iteration. After specialization, these loops are usually unrolled, since there is a fixed list of pack element types. In the unrolled code, it should be possible to eliminate the witness table lookups. This is not possible because of the @pack_element types introduced to refer to pack elements:

%5 = integer_literal $Builtin.Word, 0
%6 = dynamic_pack_index %5 of $Pack{Int, Double}
%7 = open_pack_element %6 of at <Pack{Int, Double}>, shape $each A, uuid "063BDCF4-98A3-11F0-B2E8-929C59BC796C"
%20 = witness_method $@pack_element("063BDCF4-98A3-11F0-B2E8-929C59BC796C") each A, #Numeric."*" …
%21 = apply %20<@pack_element("063BDCF4-98A3-11F0-B2E8-929C59BC796C") each A>(%10, %14, %18, %11) … // type-defs: %7

This simplification aims to eliminate all instances of @pack_element types from specialized functions by replacing those with the underlying concrete type. This allows the appropriate witness method, as well as other functions, to be inlined.

This computed attribute is used in the simplifications of witness_method, alloc_stack, unchecked_addr_cast and apply.

[eeckstein]

There is a shorter way to replace all uses: uses.replaceAll(with:).
And in combination with erasing the original instruction: SingleValueInstruction.replace(with:)

[eeckstein]

yes! You cannot replace a value with a new value which has a different type without looking at the specific using instructions.

The safest thing to do is to cast the new alloc_stack back to the original pack existential type and let other peephole optimizations clean that up:

  %1 = alloc_stack $@pack_element(...)

->

  %0 = alloc_stack $T
  %1 = unchecked_addr_cast %0 to $*@pack_element(...)

For example, if an original use is an unchecked_addr_cast itself, the resulting double address casts will be optimized away.

However, you might need to add some peephole optimizations for the address cast, e.g. optimize unchecked_addr_cast - witness_method pairs

[rjmccall]

Hmm. Can we reasonably just ask SILCloner to canonicalize this, so that we don't end up with pack_element archetypes that can be resolved to a concrete type in the first place? Otherwise I'm concerned that we're going to play whack-a-mole with every instruction that takes a type operand.

I think this can be done elegantly with a combination of

1. specializing the cloning of DynamicPackIndexInst to turn it into a ScalarPackIndexInst when the index value is an integer_literal and there's a prefix of non-expansion element types in the pack (which I don't think you're checking for), and
2. specializing the cloning of OpenPackElementInst when the index is a ScalarPackIndexInst.

The result of OpenPackElementInst is only used as a type-dependent operand for uses of the local archetype it produces, so it should be fine to simply not create a corresponding value in the clone.

You may also need to do some similar canonicalization with PackPackIndexInst; the test case is a variadic generic function that creates a larger pack, e.g.

func foo<each T>(values: repeat each T) {}
func bar<each T>(values: repeat each T) {
  foo(values: repeat each values, 1, 2, 3)
}