Ensure that the use the target specific names for the fat libraries for
non-MachO targets which do not support fat libraries. This fixes the
windows build.
Attempt to repair the build for the unified swift build. This allows us
to build a single unified toolchain with swift support. In this layout
assume that cmark and clang are peers of LLVM rather than located in
`tools`. Doing so allows a uniform layout of the tree and a simpler
build approach.
gold is more strict than lld about the order of the arguments, that's
why CMake offers two different properties for the linker: LINK_FLAGS and
LINK_LIBRARIES. The former _add_variant_link_flags was adding the
libraries to LINK_FLAGS, when the correct thing is to add them to
LINK_LIBRARIES.
The change adds a new output variable for _add_variant_link_flags which
will containt the linked libraries, and CMake will be able to generate
the correct command line invocation for when gold is used.
This should fix the Android CI build.
Windows does not link against the library but the import library. When
building the target specific bits, we unfortunately do not use the cmake
build infrastructure properly. This results in us trying to link
against libraries which do not exist. Redirect the link to the right
files. This allows us to build swift-reflection-test.
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
When building on case insensitive filesystems, there is no need to
create the library symlink forest as the paths will be resolved properly
due to the insensitivity. This avoids a bit of work and spew on
Windows.
This change could impact Swift programs that previously appeared
well-behaved, but weren't fully tested in debug mode. Now, when running
in release mode, they may trap with the message "error: overlapping
accesses...".
Recent optimizations have brought performance where I think it needs
to be for adoption. More optimizations are planned, and some
benchmarks should be further improved, but at this point we're ready
to begin receiving bug reports. That will help prioritize the
remaining work for Swift 5.
Of the 656 public microbenchmarks in the Swift repository, there are
still several regressions larger than 10%:
TEST OLD NEW DELTA RATIO
ClassArrayGetter2 139 1307 +840.3% **0.11x**
HashTest 631 1233 +95.4% **0.51x**
NopDeinit 21269 32389 +52.3% **0.66x**
Hanoi 1478 2166 +46.5% **0.68x**
Calculator 127 158 +24.4% **0.80x**
Dictionary3OfObjects 391 455 +16.4% **0.86x**
CSVParsingAltIndices2 526 604 +14.8% **0.87x**
Prims 549 626 +14.0% **0.88x**
CSVParsingAlt2 1252 1411 +12.7% **0.89x**
Dictionary4OfObjects 206 232 +12.6% **0.89x**
ArrayInClass 46 51 +10.9% **0.90x**
The common pattern in these benchmarks is to define an array of data
as a class property and to repeatedly access that array through the
class reference. Each of those class property accesses now incurs a
runtime call. Naturally, introducing a runtime call in a loop that
otherwise does almost no work incurs substantial overhead. This is
similar to the issue caused by automatic reference counting. In some
cases, more sophistacated optimization will be able to determine the
same object is repeatedly accessed. Furthermore, the overhead of the
runtime call itself can be improved. But regardless of how well we
optimize, there will always a class of microbenchmarks in which the
runtime check has a noticeable impact.
As a general guideline, avoid performing class property access within
the most performance critical loops, particularly on different objects
in each loop iteration. If that isn't possible, it may help if the
visibility of those class properties is private or internal.
Remove this special case handling for building a host library as a target
library. This is the last piece needed to support cross-compiling lldb. As a
bonus, it cleans up some of the logic in our special build system.
In https://github.com/apple/swift/pull/19973 the logic that adds "-target" when
building the C parts of the Standard Library and overlays was changed to use
CMAKE_C_COMPILER_ID to only do so when the compiler ID is "Clang". However,
on Apple toolchains the compiler ID is "AppleClang", so the target was no
longer being explicitly set.
Update the logic to relax the explicit check for "Clang" to also allow
"AppleClang".
rdar://problem/45579667
When building the target libraries, we need to install the import
library as well. Unfortunately, due to the way that the swift build
system works, we do not have the ability to rely on CMake doing the
right thing and taking care of this for us. We have to manually
construct and track the import library due to the fact that we fight the
cross-compilation support. Add some logic to extract the import
libraries and install them so that uses can actually build for Windows.
Debride the function now that it is handles only the host libraries for
the tools. These are closer in spirit to the LLVM libraries and this
function can really become a trivial wrapper around llvm_add_library.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
The Windows headers are the system (sysroot) headers. They are not
consumed by swift but the clang importer. Furthermore, they should be
treated as system headers. Correct the flags used for the invocation.
This fixes the build of the SDK overlay for Windows.
...i.e. an actual shell-like argument list, rather than a
semicolon-separated list (CMake's internal stringification mechanism
for lists). Apart from being a little easier to read, this also works
directly with the response file support in swiftc itself now (not
depending on utils/line-directive).
(It's still not /quite/ enough to expand on a command-line, though,
since that will escape the quotes. The 'sed' command can get around
that: $(sed "s/'//g" foo.txt).)
When building the swift tools with gcc, we would fail as we would try to
pass `-target` to gcc, which does not support this option. Invert the
condition and only pass the argument when building with clang.
