[sil] Do not eliminate (apply (partial_apply)) if the partial_apply captures an @in parameter and handle @in_guaranteed appropriately.

[gottesmm]

Otherwise the code as written miscompiles code like:

@inline(never)
func consumeSelf<T>(_ t : __owned T) {
  print("Consuming self!")
  print(t)
}

class Klass {}
struct S<T> {
  let t: T? = (Klass() as! T)

  @inline(__always)
  __consuming func foo(_ t: T) {
    consumeSelf(self)
  }
}

public func test<T>(_ t: __owned T) {
  let k = S<T>()
  let f = k.foo

  for _ in 0..<1024 {
    f(t)
  }
}

test(Klass())

As one can tell, without annotations it is hard to create an example like the
above, but there is no reason why we couldn't emit more code like this from the
frontend.

If the parameter is guaranteed though, the current impl is fine for
@in_guaranteed since in the loop, we do not need to retain or release the
value.

rdar://58885352

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci benchmark

[swift-ci]

Performance: -O

Regression	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	7021	9576	+36.4%	0.73x (?)
FlattenListLoop	3951	4799	+21.5%	0.82x (?)

Code size: -O

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	5049	7586	+50.2%	0.67x (?)
ObjectiveCBridgeStubFromNSDateRef	3710	4110	+10.8%	0.90x (?)

Code size: -Osize

Performance: -Onone

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

[gottesmm]

@swift-ci benchmark

[swift-ci]

Performance: -O

Code size: -O

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
DropLastArrayLazy	4	5	+25.0%	0.80x (?)
Improvement	OLD	NEW	DELTA	RATIO
DropLastCountableRangeLazy	5	4	-20.0%	1.25x (?)
FlattenListFlatMap	4728	4083	-13.6%	1.16x (?)

Code size: -Osize

Performance: -Onone

Regression	OLD	NEW	DELTA	RATIO
TypeFlood	134	151	+12.7%	0.89x (?)
ObjectiveCBridgeStubNSDateRefAccess	4073	4403	+8.1%	0.93x (?)

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

[gottesmm]

Regressions/improvements do not repro.