This is essentially a long-belated follow-up to Arnold's #12606.
The key observation here is that the enum-tag-single-payload witnesses
are strictly more powerful than the XI witnesses: you can simulate
the XI witnesses by using an extra case count that's <= the XI count.
Of course the result is less efficient than the XI witnesses, but
that's less important than overall code size, and we can work on
fast-paths for that.
The extra inhabitant count is stored in a 32-bit field (always present)
following the ValueWitnessFlags, which now occupy a fixed 32 bits.
This inflates non-XI VWTs on 32-bit targets by a word, but the net effect
on XI VWTs is to shrink them by two words, which is likely to be the
more important change. Also, being able to access the XI count directly
should be a nice win.
Rather than use a function, use a templated structure with a constant
expression to metaprogram the alignment of the type. NFC.
Adjust the templating for the SIMD vector types. Use the reserved
spelling for the clang extension, and rename the types. NFC.
The meat of this change is the explicit template specialization for the
float 3 vector and double 3 vector. Since they are going to be emitted
as float 4 vector underneath everything, we can simply treat them the
same. This has a benefit of allowing us to share the same
specialization of the witness tables. Additionally, it works around a
bug in clang where we cannot correctly decorate the extended type with
Microsoft's ABI (which is a separate issue). Since this saves some
bytes, this is still beneficial.
Rather than mapping all of the builtin floating-point and vector
types down to the type metadata symbols for power-of-two integers,
map down to the type metadata symbols provided by the runtime.
This allows us to round-trip type metadata <-> mangled name for all of
the builtin types that have such symbols. When we don’t have a runtime
symbol, we will fail to link if that builtin type gets referenced.
Expose symbols for metadata for the various builtin floating point types
and vector types. This is used by the demangler to handle builtin names.
This is a narrow fix for rdar://problem/45569984 (where we couldn’t
demangle a builtin vector type). A more extensive fix will require us
to add a general runtime facility for creating opaque type metadata
with specific size/alignment/stride/uniquing name.
The prefab'ed value witness tables for reference storage types are a
premature optimization. Not all scenarios are covered, and those that
are "look suspect" according to John McCall.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
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 standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
