Remove dead bridging calls for dead parameters

[eeckstein]

This PR consists of 2 changes:

• lazily emit shared witness tables: This avoids emitting synthesized witness tables if they are not needed.

• mark all _unconditionallyBridgeFromObjectiveC functions as @_effects(readonly): Read-only lets the optimizer remove such a call if the result is not used.
  Note that "readonly" means: no observable write operations. It's okay to allocate and initialize new objects.

rdar://problem/44944094

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci benchmark

[swift-ci]

Build comment file:

Performance: -O

TEST	OLD	NEW	DELTA	RATIO
Improvement
NSStringConversion	717	0	-100.0%	717001.00x

Code size: -O

TEST	OLD	NEW	DELTA	RATIO
Improvement
NSStringConversion.o	873	793	-9.2%	1.10x

Performance: -Osize

TEST	OLD	NEW	DELTA	RATIO
Regression
StringWalk	1699	2008	+18.2%	0.85x
Improvement
NSStringConversion	732	0	-100.0%	732001.00x

Code size: -Osize

TEST	OLD	NEW	DELTA	RATIO
Improvement
NSStringConversion.o	938	858	-8.5%	1.09x

Code size: Swift libraries

TEST	OLD	NEW	DELTA	RATIO
Improvement
libswiftCryptoTokenKit.dylib	28672	24576	-14.3%	1.17x
libswiftNaturalLanguage.dylib	45056	40960	-9.1%	1.10x
libswiftNetwork.dylib	172032	163840	-4.8%	1.05x
libswiftXCTest.dylib	86016	81920	-4.8%	1.05x
libswiftAppKit.dylib	86016	81920	-4.8%	1.05x
libswiftCloudKit.dylib	106496	102400	-3.8%	1.04x

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

---

[aroben]

Ah, nice!

Is there a way to make @_effects(readonly) automatic in this case, or to otherwise ensure that it is applied to any new _unconditionallyBridgeFromObjectiveC functions that may get added in the future? It'd be a shame for some new datatype to lose out on this optimization just because the annotation was overlooked.

[eeckstein]

Yes, the compiler could enforce this based on the annotation on the protocol requirement.
I created https://bugs.swift.org/browse/SR-8953 for this.

[slavapestov]

Bad indent here

[eeckstein]

interesting. This file has tab indents.
I'll fix it.

[slavapestov]

Can you also CHECK-NOT that the witness table was not emitted?

[eeckstein]

This test check the SIL. And in SIL the witness tables do get emitted.
For the IRGen part, I put in a CHECK-NOT in test/IRGen/objc_ns_enum.swift

[phausler]

from the Foundation overlay this looks fine to me

[phausler]

one quick question however, does this apply to linux bridging as well?

[eeckstein]

@swift-ci smoke test and merge

[eeckstein]

@swift-ci smoke test and merge

[eeckstein]

@phausler good point. Yes, it would make sense to add the annotations in swift-corelibs-foundation as well.

[aroben]

The benchmark output suggests NSStringConversion isn't doing any work anymore. Do we need to modify that test so that it actually performs the conversions? Or maybe there's some other test that covers that, and thus it's a good thing to have this test indicate that the work is skipped when the stores are dead?

[eeckstein]

I'll fix the benchmark in a follow-up PR