This applies more annotations in the `INTERNAL_CHECKS_ENABLED` disabled
paths, Windows, 32-bit, and non-ObjC paths. Interestingly enough, there
are a couple of compiler intrinsics which are also uncovered.
Making it transparent evidently induces new retain/release traffic in Array’s subscript, even though I can find no indication that `ClosedRange.contains` is ever called by that code path. Oh well.
These are really popular shorthands for implementing bounds checks, but currently they aren’t even marked `@inline(__always)`, so in larger functions they tend to remain outlined, defeating optimizations that would otherwise happen.
The corresponding variants on the partial range types are `@_transparent`; that helps unoptimized performance, so let’s apply the same attribute here.
rdar://151177326
There's no reason for these to ever be calls, so they should be
transparent instead of just aEIC. Also adds concrete versions of
comparisons with scalars, and filecheck tests to make sure these
generate 1-2 instruction sequences in release on arm64 (x86_64 is a
little trickier to test due to frame pointers, but if we get the right
codgen on arm64, in practice we do well on x86_64 for these too).
Also makes filecheck patterns for repeating initializers a bit more
robust.
The PR #81766 introduced some concrete SIMD operations, but
`init(repeating:)` was temporarily disabled due to differentiation
testing break. See:
7a00619065
This PR contains two changes:
1. Define custom derivatives for concrete `init(repeating:)` so we do
not fall into non-differentiability error diagnostic.
2. Add a fix to SIL linker so differentiability witness lookup is done
when the original function has both `@_alwaysEmitIntoClient` and
`@_transparent`. Similar changes were introduced previously in #78908,
but they only handled `@_alwaysEmitIntoClient` without `@_transparent`.
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
