[silgenpattern] Allow the initial switch value to be at +0 if it is loadable.

[gottesmm]

This commit allows the initial switch subject value to be emitted at +0 if we
can emit it that way. As you can imagine since we have +0 normal function
arguments this should tighten up a lot of code around switches on arguments. So
I got to delete a bunch of code in the tests. = ).

Some things to note:

1. If the switch is given a +1 value, we will still try to let it through at +1
   until we hit a part of the decision tree where previously we would need to use
   TakeOnSuccess. This means that +1 values that go through irrefutable patterns
   like tuple splitting should still be emitted at +1.

2. If we are returned an address only type without a cleanup, we copy it and
   pass it down at +1 like the old code.

3. I also elided the last ownership check in SILGenPattern in this commit. After
   this, there is only 1 specialization for ownership in the swift compiler that is
   in Apply emission. Thats my next target.

rdar://29791263

---

The commit to review is the last one.

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test source compatibility

[gottesmm]

@swift-ci smoke benchmark

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 91a7e395a48079ca8b47a365cb29caf8cc2fd7a9

[swift-ci]

Build comment file:

Performance: -O

TEST	OLD	NEW	DELTA	RATIO
Improvement
IterateData	1778	1617	-9.1%	1.10x

Performance: -Osize

TEST	OLD	NEW	DELTA	RATIO
Improvement
IterateData	1806	1589	-12.0%	1.14x

Code size: -Osize

TEST	OLD	NEW	DELTA	RATIO
Improvement
Calculator.o	3021	2957	-2.1%	1.02x

Performance: -Onone

TEST	OLD	NEW	DELTA	RATIO
Regression
ArrayPlusEqualFiveElementCollection	229812	270291	+17.6%	0.85x
Improvement
ObjectiveCBridgeStubFromArrayOfNSString2	3860	3589	-7.0%	1.08x (?)

Code size: Swift libraries

TEST	OLD	NEW	DELTA	RATIO
Regression
libswiftCryptoTokenKit.dylib	24576	28672	+16.7%	0.86x

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

---

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 91a7e395a48079ca8b47a365cb29caf8cc2fd7a9

[atrick]

LGTM. Clearly emitting better SIL. I feel like we'll need cast ownership optimizations eventually.

[gottesmm]

Debug reactive cocoa/reactive swift failure is already there:

https://ci.swift.org/job/swift-master-source-compat-suite-debug/342/console

[gottesmm]

Fixed the tests.

[gottesmm]

@swift-ci smoke test and merge

[gottesmm]

@swift-ci smoke test and merge

[gottesmm]

@swift-ci smoke test and merge

[gottesmm]

@swift-ci smoke test and merge