* Make the underlying builtins for FP + Vector match Integer.
For stdlib integer types, these are named `_value` and `init(_ _value: Builtin.xxx)`. This patch adopts the same scheme for stdlib floating point and SDK overlay vector types, and removes a legacy init for integers that was only needed to support them. There should be no changes visible outside of the stdlib, and no functional change within the stdlib; the naming of some implementation details is simply more uniform now.
...as detected by initializing an individual field without having
initialized the whole object (via `self = value`).
This only applies in pre-Swift-5 mode because the next commit will
treat all cross-module struct initializers as delegating in Swift 5.
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
This is a staging attribute that will eventually mean "fixed-contents"
for structs and "closed" for enums, as described in
docs/LibraryEvolution.rst.
This is pretty much the minimal set of types that must be fixed-layout,
because SILGen makes assumptions about their lowering.
If desired, some SILGen refactoring can allow some of these to be
resilient. For example, bridging value types could be made to work
with resilient types.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
Checked arithmetic is probably not what you want from the vector unit, but we still want code to be explicit about the fact that it's using wrapping semantics instead of trapping or UB semantics. Provide the wrapping variations of the operators, and leave behind unavailable definitions to direct users to the wrapping operations if they try to use the standard ones.
Swift SVN r30008
This brings the David Owens benchmark from http://owensd.io/2015/06/27/performance-xcode7-beta-2.html from parity with simd.h-based C to 3x faster.
Before:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 7.035851 │ 6.304739 │ 9.815832 │ 1.212 │
After:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 2.318357 │ 2.223325 │ 2.697981 │ 0.1490 │
This also addresses rdar://problem/21574425, since Builtin.add_VecNxIntM isn't overflow-checked, and overflow checks really aren't wanted when working with vector types directly.
Reapplying now that Nadav's fixed the ARM64 SelectionDAG issue this exposed before, and Arnold's fixed
yet another SelectionDAG issue exposed after that.
Swift SVN r30006
Revert "simd overlay: Use LLVM vector types."
This reverts commit r29922 and r29924.
More arm64 instruction selection errors.
rdar://21703486
Swift SVN r29941
This brings the David Owens benchmark from http://owensd.io/2015/06/27/performance-xcode7-beta-2.html from parity with simd.h-based C to 3x faster.
Before:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 7.035851 │ 6.304739 │ 9.815832 │ 1.212 │
After:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 2.318357 │ 2.223325 │ 2.697981 │ 0.1490 │
This also addresses rdar://problem/21574425, since Builtin.add_VecNxIntM isn't overflow-checked, and overflow checks really aren't wanted when working with vector types directly.
Reapplying now that Nadav's fixed the ARM64 SelectionDAG issue this exposed before.
Swift SVN r29922
This brings the David Owens benchmark from http://owensd.io/2015/06/27/performance-xcode7-beta-2.html from parity with simd.h-based C to 3x faster.
Before:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 7.035851 │ 6.304739 │ 9.815832 │ 1.212 │
After:
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD)) │ 2.318357 │ 2.223325 │ 2.697981 │ 0.1490 │
This also addresses rdar://problem/21574425, since Builtin.add_VecNxIntM isn't overflow-checked, and overflow checks really aren't wanted when working with vector types directly.
Swift SVN r29891
The case where this comes up is when people name their app and framework
targets the same thing, or when they've renamed their test target module
in an attempt to avoid issues with NSClassFromString and differing
runtime names. We currently do various wrong things when this happens,
so just emit an error instead.
I left a hole for our overlays, which use '@exported import <the-current-module>'
to get at their Clang modules. The previous commit means this can be
replaced by -import-underlying-module, but that doesn't help our tests,
which use -enable-source-import for their overlays. Which we should stop doing.
rdar://problem/21254367
Swift SVN r29440
