[arc] Change guaranteed arc opts to be based on SemanticARCOpts and move from Diagnostic pipeline -> Onone pipeline.

[gottesmm]

The pass is already not being run during normal compilation scenarios today
since it bails on OSSA except in certain bit-rot situations where a test wasn't
updated and so was inadvertently invoking the pass. I discovered these while
originally just trying to eliminate the pass from the diagnostic pipeline. The
reason why I am doing this in one larger change is that I found there were a
bunch of sil tests inadvertently relying on guaranteed arc opts to eliminate
copy traffic. So, if I just removed this and did this in two steps, I would
basically be unoptimizing then re-optimizing the tests.

Some notes:

1. The new guaranteed arc opts is based off of SemanticARCOpts and runs only on
   ossa. Specifically, in this new pass, we just perform simple
   canonicalizations that do not involve any significant analysis. Some
   examples: a copy_value all of whose uses are destroys. This will do what the
   original pass did and more without more compile time. I did a conservative
   first approximation, but we can probably tune this a bit.

2. the reason why I am doing this now is that I was trying to eliminate the
   enable-ownership-stripping-after-serialization flag and discovered that the
   test opaque_value_mandatory implicitly depends on this since sil-opt by
   default was the only place left in the compiler with that option set to false
   by default. So I am eliminating that dependency before I land the larger
   change.

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]

Once this is done, I am going to remove that flag and then I am going to start moving the ownership lowering down the pipeline a bit.

[gottesmm]

@swift-ci benchmark

[swift-ci]

Performance: -O

Improvement	OLD	NEW	DELTA	RATIO
String.data.LargeUnicode	122	109	-10.7%	1.12x (?)

Code size: -O

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
Data.init.Sequence.511B.Count.I	92	116	+26.1%	0.79x
Data.init.Sequence.513B.Count.I	93	106	+14.0%	0.88x (?)
DataSetCountMedium	320	350	+9.4%	0.91x (?)
Improvement	OLD	NEW	DELTA	RATIO
FlattenListLoop	2464	1653	-32.9%	1.49x (?)
FlattenListFlatMap	6046	4922	-18.6%	1.23x (?)
NSStringConversion.MutableCopy.Rebridge.UTF8	740	690	-6.8%	1.07x (?)

Code size: -Osize

Performance: -Onone

Improvement	OLD	NEW	DELTA	RATIO
DataCreateSmallArray	106600	97900	-8.2%	1.09x (?)
Data.hash.Small	359	334	-7.0%	1.07x (?)

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

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 897d264fec8166f3138b0e3e783d6b1dba9883d3

[gottesmm]

32 bit strike again! :doh:

[gottesmm]

Nope, I was wrong. Actual problem was that on 32 bit we were changing the struct to be indirect. So not a direct 32/64 bit issue.

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 702c1bc

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 702c1bc

[gottesmm]

@swift-ci smoke test OS X platform

[gottesmm]

@swift-ci test

[lxbndr]

@gottesmm
I was looking for the source of compilation speed regression I observe lately. And I think this change is the best candidate. Previous commit seems ok. Disabling optimization manually via -Xllvm -sil-disable-pass=GuaranteedARCOpts also helps.

I am compiling https://github.com/manGoweb/MimeLib on Windows. It consists of only three source files. One of them is huge enum with about 300+ cases. And another one contains two big switch statements using that huge enum.

Normally it takes about 10 seconds to build, but now it is about 20 minutes.

[gottesmm]

@lxbndr can you file a bug on bugs.swift.org and post the bug # here?

[lxbndr]

@gottesmm
https://bugs.swift.org/browse/SR-13205