[stdlib] Simplify 'BinaryFloatingPoint.init?<T: BinaryFloatingPoint>(exactly: T)'

[xwu]

This PR replaces an unconditional invocation of the generic BinaryFloatingPoint._convert in the default implementation of BinaryFloatingPoint.init?<T: BinaryFloatingPoint>(exactly: T) with a more thoughtful alternative to take advantage of fast paths introduced in #33803 and #33826.

Specifically, the logic for determining if a value can be exactly represented is extracted from BinaryFloatingPoint._convert to enable early exits returning nil. If the value can be represented exactly, then we invoke BinaryFloatingPoint.init<T: BinaryFloatingPoint>(T), which has the aforementioned fast paths.

A test is updated to correspond with this change.

[xwu]

@swift-ci test

[xwu]

/cc @troughton

[stephentyrone]

I think we can simplify the logic downstream by pulling out zero and infinity here (since both are always exact). WDYT?

[xwu]

@stephentyrone I left it out because, when specialized, the case of Float-to-Double would be a single 'isNaN' check followed by conversion. Checking for finite nonzero values would have to be written separately anyway, since it wouldn't return nil; this is what happens here already. The only difference is whether it can be short-circuited or not when the concrete types are known; the logic doesn't otherwise get any simpler, and I'd like to be able to short circuit that check when it's not necessary.

[xwu]

@swift-ci benchmark

[swift-ci]

Performance: -O

Improvement	OLD	NEW	DELTA	RATIO
ConvertFloatingPoint.MockFloat64Exactly	680	5	-99.3%	135.97x
ConvertFloatingPoint.MockFloat64Exactly2	1013	16	-98.4%	63.31x
NopDeinit	9900	8800	-11.1%	1.12x

Code size: -O

Regression	OLD	NEW	DELTA	RATIO
FloatingPointConversion.o	41265	41821	+1.3%	0.99x

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	2987	4001	+33.9%	0.75x (?)
Improvement	OLD	NEW	DELTA	RATIO
ConvertFloatingPoint.MockFloat64Exactly	675	5	-99.3%	134.97x
ConvertFloatingPoint.MockFloat64Exactly2	1017	17	-98.3%	59.82x
NopDeinit	11000	9900	-10.0%	1.11x (?)

Code size: -Osize

Regression	OLD	NEW	DELTA	RATIO
FloatingPointConversion.o	39406	39858	+1.1%	0.99x

Performance: -Onone

Regression	OLD	NEW	DELTA	RATIO
DataAppendDataSmallToSmall	2840	3140	+10.6%	0.90x (?)
Improvement	OLD	NEW	DELTA	RATIO
ConvertFloatingPoint.MockFloat64Exactly2	1592	707	-55.6%	2.25x
ConvertFloatingPoint.MockFloat64Exactly	773	489	-36.7%	1.58x

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

[xwu]

@stephentyrone Are you good with merging this?

[xwu]

Hey @stephentyrone, just another ping. If no objections, I'll go ahead and get this one merged. Thanks!

[stephentyrone]

Ship it.