[5.3] SILOptimizer: A new "TempLValueOpt" optimization for copy_addr

[atrick]

Cherry-picking this PR to 5.3 to unblock performance for
#32041

[atrick]

@swift-ci test

[atrick]

@swift-ci test source compatibility

[atrick]

@swift-ci benchmark

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - ed2e6fb

[atrick]

@swift-ci test

[atrick]

--- CCC ---
Explanation: Add a peephole optimization to remove temporary copies of enums with existential payloads.

Radar: rdar://65755048 (Add the TempLValue SIL optimization to the 5.3 swift release branch)

Require to unlock performance fixes from this PR:
#32041

Scope: At -O, removes copies of more structurally complex values.

Risk: The optimization is restricted to a very limited input pattern and I've carefully reviewed the code. It could expose bugs in AliasAnalysis, but more testing exposure to core SIL analyses is generally good.

Testing: New unit tests and existing compatibility tests were run.

Reviewer: Andrew Trick

[atrick]

Explanation:

TempLValueOpt is designed to handle this case.

public enum Either<Left, Right> {
  case left(Left), right(Right)
}

internal struct AddressOnlyPayload {
  let a: Any
  let i: Int
}

public struct TestStruct {
  internal var e: Either<AddressOnlyPayload, Int>

  public init(_ a: Any, _ i: Int) {
    // Construct Either in-place.
    e = Either.left(AddressOnlyPayload(a: a, i: i))
  }
}

TempLValueOpt is conceptually much simpler than CopyForwarding for two key reasons:

• it relies on the presence of AliasAnalysis (a non-goal for CopyForwarding).

• it only recognizes copies where the source lifetime is clearly
  disjoint from the destination by scanning a short sequence of
  instructions (when CopyForwarding was written, SILGen already
  handled trivial copies)

SILGen was changed over time to eliminate less copies and AliasAnalysis improved. In response, we added a simpler TempRValueElimination to handle obvious copies. By calling AliasAnalysis it is potentially expensive, but in a sense more general because it only needs to analyze the use-patterns of the temporary value, not the use-patterns of the copied value.

The new TempLValueOpt is the just the backward form of TempRValueElimination. It is considerably simpler even than TempRValueElimination because it assumes the alloc_stack and dealloc_stack instructions are in the same block as the copy.

[atrick]

@airspeedswift benchmark PR testing appears to be broken, but the benchmarks did at least build and run locally, so I'll go ahead and merge.