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
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
Enable CMake policy CMP0057, which allows `if()` statements to use the `IN_LIST`
operator. In addition, simplify several `if()` statements that used the
`list(FIND ...)` operation instead.
Add an option which the user can specify to switch to the lld linker. Although
this linker is still nascent, it is interesting to permit linking with this. It
is also an alternative to the BFD linker for COFF targets. It will allow for a
cross-compilation story for Windows on non-Windows targets.
This is the only site which allowed you to accidentally accept gold for targets
which are not ELFish. For the time being, we can only add unit tests for the
host variant, so use the `SWIFT_HOST_VARIANT_SDK` to determine the target file
format. This will make supporting cross-compiling to non-ELFish targets
simpler.
*NOTE* We are still passing this variable into LLVM. Just not into Swift anymore.
I originally passed in the variable -DLLVM_ENABLE_LTO=YES to Swift's cmake to
ensure that the Swift unittests were compiled with lto. That was the wrong
fix.
The reason why is that if -DLLVM_ENABLE_LTO is set to YES then HandleLLVMOptions
in llvm will append -flto to both CMAKE_C_FLAGS and CMAKE_CXX_FLAGS implying
that -flto can not be disabled selectively. This ability to disable flto
selectively is something that we need in order to lto host libraries, but not
lto target libraries.
Thus in this commit, we no longer pass in -DLLVM_ENABLE_LTO=YES to swift's cmake
invocation. Instead we apply the lto flag to the unittest target ourselves in
add_swift_unittest.
rdar://24717107
