[stdlib] Make Range.init(_: ClosedRange<Bound>) inlinable

[troughton]

Currently, a simple Range.init(_: ClosedRange<Bound>)-calling function such as:

func makeSingleElementRange(n: Int) -> Range<Int> {
    return Range(n...n)
}

will perform unspecialised generic calls under optimisation because Range.init(_: ClosedRange<Bound>) is not inlinable:

output.makeSingleElementRange(n: Swift.Int) -> Swift.Range<Swift.Int>:
        sub     rsp, 40
        mov     qword ptr [rsp + 8], rdi
        mov     qword ptr [rsp + 16], rdi
        call    (lazy protocol witness table accessor for type Swift.Int and conformance Swift.Int : Swift.SignedInteger in Swift)
        mov     rcx, rax
        mov     rsi, qword ptr [rip + ($sSiN)@GOTPCREL]
        mov     rdx, qword ptr [rip + ($sSiSxsWP)@GOTPCREL]
        lea     rax, [rsp + 24]
        lea     rdi, [rsp + 8]
        call    ($sSnsSxRzSZ6StrideRpzrlEySnyxGSNyxGcfC)@PLT
        mov     rax, qword ptr [rsp + 24]
        mov     rdx, qword ptr [rsp + 32]
        add     rsp, 40
        ret

Mark the init as inlinable so these functions can be properly optimised.

Also add a missing line of documentation.

[CodaFi]

@swift-ci smoke test

[CodaFi]

@swift-ci benchmark

[swift-ci]

Performance (x86_64): -O

Regression	OLD	NEW	DELTA	RATIO
FlattenListLoop	1730	2552	+47.5%	0.68x (?)
FlattenListFlatMap	5770	6463	+12.0%	0.89x (?)
Improvement	OLD	NEW	DELTA	RATIO
ObjectiveCBridgeToNSDictionary	18650	17400	-6.7%	1.07x (?)

Code size: -O

Performance (x86_64): -Osize

Regression	OLD	NEW	DELTA	RATIO
ArrayAppendGenericStructs	1330	2220	+66.9%	0.60x (?)
NSStringConversion.Rebridge.Medium	172	185	+7.6%	0.93x (?)
Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	6802	5840	-14.1%	1.16x (?)

Code size: -Osize

Performance (x86_64): -Onone

Improvement	OLD	NEW	DELTA	RATIO
ArrayAppendOptionals	2060	1370	-33.5%	1.50x (?)
StringBuilderWithLongSubstring	4810	4220	-12.3%	1.14x (?)
NSError	719	660	-8.2%	1.09x (?)

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

[troughton]

Is there anything else that's needed here? I assume the benchmark changes are spurious – I had a quick look and didn't spot anything that would obviously be affected by this change.

[troughton]

@CodaFi Would you mind reviewing this or suggesting someone for review?

[Catfish-Man]

Looks fine to me!

[CodaFi]

⛵