SILCombine: optimize casts of existential boxes.

[eeckstein]

Optimize the unconditional_checked_cast_addr in this pattern:

   %box = alloc_existential_box $Error, $ConcreteError
   %a = project_existential_box $ConcreteError in %b : $Error
   store %value to %a : $*ConcreteError
   %err = alloc_stack $Error
   store %box to %err : $*Error
   %dest = alloc_stack $ConcreteError
   unconditional_checked_cast_addr Error in %err : $*Error to ConcreteError in %dest : $*ConcreteError

to:

   ...
   retain_value %value : $ConcreteError
   destroy_addr %err : $*Error
   store %value to %dest $*ConcreteError

This lets the alloc_existential_box become dead and it can be removed in following optimizations.
The same optimization is also done for conditional_checked_cast_addr.

There is also an implication for debugging:
Each "throw" in the code calls the runtime function swift_willThrow. The function is used by the debugger to set a breakpoint and also add hooks.
This optimization can completely eliminate a "throw", including the runtime call.
So, with optimized code, the user might not see the program to break at a throw, whereas in the source code it is actually throwing.
On the other hand, eliminating the existential box is a significant performance win and we don't guarantee any debugging behavior for optimized code anyway. So I think this is a reasonable trade-off.
I added an option "-Xllvm -keep-will-throw-call" to keep the runtime call which can be used if someone want's to reliably break on "throw" in optimized builds.

To make this optimization work smoothly with the Result type from the library, I had to make the Result methods inlinable. For a use case see the SILOptimizer/existential_box_elimination.swift test file.

rdar://problem/66055678

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci benchmark

[eeckstein]

@fredriss do you have any concerns regarding the implication for debugging (see my comment in the description)?

[swift-ci]

Performance: -O

Improvement	OLD	NEW	DELTA	RATIO
DropFirstArrayLazy	14	13	-7.1%	1.08x (?)

Code size: -O

Performance: -Osize

Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	4225	3797	-10.1%	1.11x (?)
FlattenListLoop	1522	1419	-6.8%	1.07x (?)

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 mini
  Model Identifier: Macmini8,1
  Processor Name: 6-Core 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

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 61d8bbd92dff1a6ee29c5412c911e16782dc64a3

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 61d8bbd92dff1a6ee29c5412c911e16782dc64a3

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 61d8bbd92dff1a6ee29c5412c911e16782dc64a3

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 61d8bbd92dff1a6ee29c5412c911e16782dc64a3

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci test