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
struct methods. This does not including properties and subscripts,
but covers the bulk of the change. The implication of this is that
the compiler now rejects mutations of self in a non-@mutating method,
and rejects attempts to call a @mutating method from a non-@mutating
method.
Along with this:
- Fix a refcounting bug in SILGenExpr where I emitted multiple releases
in the rvalue member_ref_expr case, which was exposed by the
testsuite now that rvalues are being used a lot more.
- Change a few native binding things in objc/Foundation to understand
that String is passed by value now when calling size() and that
you can't take the address of self in a non-mutating method (this
should probably pass the components by value instead of passing
&self, for better performance). I filed rdar://15726720 to track
this.
- Update a ton of testcases. We now don't materialize nearly as much
as we used to.
- Brutalize the test/stdlib/Getopt.swift testcase to work, now that
the "GetoptLongOptions().noArgument("foo")" builder pattern doesn't
work anymore (noArgument is a @mutating method, which isn't allowed
on an rvalue temporary).
Swift SVN r11662
If there's no script-mode file in a module, don't produce a top_level_code SILFunction for it, and don't consider emitting an LLVM global_ctor for it. We should never emit static constructors from user code anymore.
Swift SVN r11644
