This is easier for out-of-process clients like LLDB or DTrace to understand, and will let us mess with the runtime metadata cache data structure without forcing churn on the debugger team.
Swift SVN r13221
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
The previous attempt at this failed because tuple type metadata was laid out in a way that smashed the metadata cache key. Cache keys used to be laid out like this:
CacheEntry struct
-----------------
cache key
-----------------
variable-sized payload
And TupleTypeMetadata tried to tail-emplace its element array immediately after the main CacheEntry, forgetting the cache key was there. When we actually try to use that cache key to implement a hash table, bad things happen. Rearrange cache entries into the less error-prone layout:
cache key
-----------------
CacheEntry struct
-----------------
variable-sized payload
This also nicely avoids the need for a dynamic offset from the CacheEntry struct to its payload. A tail-allocated payload is likely to be more hot than the cache key, which is only needed at instantiation and lookup time.
Swift SVN r13205
- Int and UInt are now struct types backed by Builtin.Word. Previously they
were typealiases for Int64; Int and Int64 are now distinct types.
- Mangled names 'i' and 'u' are now Int and UInt. Int64 is mangled longhand.
- Word is a typealias for Int. It is expected to go away in the future.
- Builtin.Word is unchanged.
- CLong and CUnsignedLong are typealiases for Int and UInt.
- FixedPoint.swift is now FixedPoint32.swift and FixedPoint64.swift.
Reunifying these requires better builtins, especially for checked
conversions (rdar://15472770).
- Updated many tests, mostly because Int is no longer spelled Int64 in sil.
- One check was removed from test decl/operator/operators.swift
because it changed behavior when Int became a non-typealias
type (rdar://15934688).
Swift SVN r13109
When SWIFT_OPTIMIZED is not set, add a little extra memory debugging,
which doesn't seem to slow anything down noticeably and can be disabled
as needed.
This change only affects the CMake build because that's the only place
where SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS is supported already. We may
want to extend this to the Makefile build.
Swift SVN r13008
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
Swift SVN r12998
The facility we had before was not very usable in core elements of the
standard library because it relied too much on those elements itself.
The result could be some spectacular infinite recursions and general
erosion of certainty, and was making development of Swift's String very
difficult.
In this commit we use extremely low-level primitives to avoid the recursion
problem. Also, because the purpose of all the older assertion functions
was unclear and there was a great deal of overlap in terms of
functionality, we clarify naming and consolidate functions.
As much as possible, the semantics of all existing tests in the face of
Asserts-enabled/-disabled build configuration changes has been
preserved, but the new naming makes it obvious in some cases that the
semantics may not have been well-chosen, which speaks well for the new
names. (**)
The two forms of "assert()" are completely enabled or
disabled--including evaluation of the condition--based on build
configuration. This follows the usual semantics from C, with the
differences being:
* No multiple evaluation badness from preprocessor macros, of course
* When a condition is supplied, assert accepts an optional message
* When no condition is supplied, fires unconditionally and requires a
message
The other functions are always enabled and only differ between build
configurations in how much information they attempt to deliver through
non-core-dump channels. When assertions are disabled and these
functions fire, they invoke a debugger trap, and do nothing else.
(**) It also opens some questions about policy. For example, should we
consider overflow and underflow to be securityChecks, as we do now, even
though they do not directly cause a memory safety issue? We could wait
for e.g. bounds checking on arrays to catch those problems before they
become memory safety issues, and gain a little speed in the regular
arithmetic path.
Swift SVN r12854
This lets IRGen avoid emitting an alloca for common generic metadata instantiations. These entry points can also be marked "readnone", and the general getGenericMetadata entry point can be "readonly", giving LLVM's optimizer a fighting chance on unspecialized generic code.
Swift SVN r12789
The core datastructure of the revised and optimized String Design Redux,
Part Trois. Completely untested and not wired into anything, so NFC.
Swift SVN r12701
...which would of course prevent them from being used. Sadly, this includes
the one I just added, since I didn't actually test it against the original
project until now.
Add a regression test that all block shims have valid manglings without
any unmangled suffixes.
Swift SVN r12672
...which is used for the first argument to
+[NSAnimationContext runAnimationGroup:completionHandler:].
Also, use the existing shims for NSFileCoordinator's NSURL-taking blocks;
they are equivalent to the shims that take id.
We really need to figure out how to do this (a) more generically (i.e. all
id-compatible types are treated the same), and (b) on the fly for the more
esoteric block types.
<rdar://problem/15864611>
Swift SVN r12668
Going through an @objc protocol for bridging Cocoa strings to Swift
String was working, but it had several disadvantages, including the cost
of invoking objc_msgsend and the need to viciously cast away type-safety
to get past swift's ObjC bridging restrictions.
Instead, Swift's core stdlib now contains a couple of "function
pointers" (variables of Optional<some-Swift-function-type>) that are set
when Foundation is loaded. We use C++ dynamic initialization to set up
these variables, which is probably not the right long-term answer, but
works for now.
These functions, instead of invoking objc methods on NSString, go
through CFStringXXX functions, which have a fast path that avoids
objc_msgsend in Cocoa's common cases, and since they're not @objc
methods, they can use Swift's full type vocabulary.
It would still be nice to avoid any dynamic dispatch and checking
overheads for going through these optional function variables, but this
ought to be a lot better than where we were, and it keeps Foundation
decoupled from the core standard library.
Along the way, a fair amount of needless code bulk was shed. Shedding
FTW!
Swift SVN r12327
We can now run it from the repl:
Welcome to swift. Type ':help' for assistance.
(swift) benchStrings()
8808796493 nanoseconds on x86
(swift)
Swift SVN r12242
C++: ~231326 ns
ObjC: ~750604 ns
Swift: ~5827396474 ns == 25191x slower than C++!
The problems are all over the place. For example: while there are lots
of failures to inline generics, there is work in the runtime as well to
fix some cases where we call calloc() instead of use the swift cache.
Swift SVN r12225
1) Abstract away assumptions about all LLVM types being prefixed by 'Int'.
2) Thread through the ability to create a "word" sized type. This is
blocked by a couple bugs.
3) Fix a bug where Int8/UInt8 did not conform to ArrayBounds.
(This bug dates back to when FixedPoint.swift was hand maintained.)
Swift SVN r11858
This change is as minimal as possible, which means leaving obsolete
functionality in place (e.g. StringByteData) and even keeping the
"NewString" name in many places. The obsolete functionality was useful
for testing my changes, but expect immediate cleanup commits
addressing all those issues to follow.
* All String bridging now happens in pure Swift code.
* Because String no longer owns an array of UInt8, some assumptions and
assertions are no longer valid. As a result, some code was deleted
and all the code that produces null-terminated strings had to be
rewritten
* test/Constraints/construction.swift had to have one test commented out
because it relied on an element of the String interface that I did not
port forward. It seems to me that this test should declare its own
types and not rely on the stdlib, if it's still valid.
* One test in /test/stdlib/Algorithm.swift had to be disabled pending
<rdar://problem/15736729> and <rdar://problem/15733855>
* This change revealed that test/Interpreter/repl.swift is sensitive to
type-alias names; I had to change a "NewString" to "String" there.
This may indicate a bug somewhere?
Swift SVN r11830
