* Omit leaf frame pointers on i686 architectures
This is x86. See the root CMakeLists.txt file
```
elseif("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86")
set(SWIFT_HOST_VARIANT_ARCH_default "i686")
```
* Use the correct flags to omit leaf frame pointers with clang-cl and MSVC
* Don't omit leaf frame pointers on 64 bit architectures
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
Expanding this at include time doesn't work correctly for LLDB because the variable conventions aren't consistent. Expanding and configure time means the Swift variables get expanded and passed along.
Since Swift's build tree configuration depends on CMark, we should also include the CMark targets if they are not present and the Exports file is available.
This patch generates SwiftExports.cmake and SwiftConfig.cmake in the build tree to be compatible with CMake's `find_package` function for importing targets between CMake build trees. This will allow LLDB to consume Swift's targets and infer their transitive dependencies.
This should fix out-of-tree LLDB builds.
This patch overrides the output directories setup by llvm_add_library.
This is required because swift deviates from the LLVM convention of using the LLVM_*_INTDIR variables.
This was causing failures on LLDB's PR testing because LLDB has a terrible mechanism for picking the swift libraries. It finds all the .a files by searching a directory.
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
This seems to more than fix a performance regression that we
detected on a metadata-allocation microbenchmark.
A few months ago, I improved the metadata cache representation
and changed the metadata allocation scheme to primarily use malloc.
Previously, we'd been using malloc in the concurrent tree data
structure but a per-cache slab allocator for the metadata itself.
At the time, I was concerned about the overhead of per-cache
allocators, since many metadata patterns see only a small number
of instantiations. That's still an important factor, so in the
new scheme we're using a global allocator; but instead of using
malloc for individual allocations, we're using a slab allocator,
which should have better peak, single-thread performance, at the
cost of not easily supporting deallocation. Deallocation is
only used for metadata when there's contention on the cache, and
specifically only when there's contention for the same key, so
leaking a little isn't the worst thing in the world.
The initial slab is a 64K globally-allocated buffer.
Successive slabs are 16K and allocated with malloc.
rdar://28189496
In Xcode builds the library dir variable contains the build configuration in the path, but the exports file doesn't. If we construct the export file path from the build directory instead of the library directory it should all work.
This should help speed up people trying to compile the standard library and do
SILGen work. *NOTE* This will not necessarily result in a type checker that is
as fast as a release build since most likely the type checker will use some
link_once odr functions that are debug. But it should still be significantly
faster otherwise.
This makes getting to SILGen take 16 seconds on my machine instead of forever
when compiling with everything else in the compiler in debug mode.
Do not add the (default) system include path as a system include path.
Doing so results in a `-isystem /usr/.../include`. This changes the
include ordering, resulting in the failure to include headers from the
system when building the standard library. This breaks compilation on
exherbo which uses a slightly different directory structure
(/usr/include -> /usr/host/include -> /usr/<target>/include). If the
paths are canonicalised during the build, we would then add
/usr/<target>/include to the CPPFLAGS, resulting in the failure to
include C headers. Unfortunately, this is insufficient as another site
is also including the path as a SYSTEM include path. But, this is still
strictly an improvement.
This seems to more than fix a performance regression that we
detected on a metadata-allocation microbenchmark.
A few months ago, I improved the metadata cache representation
and changed the metadata allocation scheme to primarily use malloc.
Previously, we'd been using malloc in the concurrent tree data
structure but a per-cache slab allocator for the metadata itself.
At the time, I was concerned about the overhead of per-cache
allocators, since many metadata patterns see only a small number
of instantiations. That's still an important factor, so in the
new scheme we're using a global allocator; but instead of using
malloc for individual allocations, we're using a slab allocator,
which should have better peak, single-thread performance, at the
cost of not easily supporting deallocation. Deallocation is
only used for metadata when there's contention on the cache, and
specifically only when there's contention for the same key, so
leaking a little isn't the worst thing in the world.
The initial slab is a 64K globally-allocated buffer.
Successive slabs are 16K and allocated with malloc.
rdar://28189496
