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
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.
Now that I am going to be adding an IN_SWIFT_COMPONENT argument, I need to do
this to distinguish the concepts of an LLVM_COMPONENT and a SWIFT_COMPONENT.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
It's like LLVM's MergeFunctions pass, except that it can also merge functions which differ by some constants.
The intention is to merge specialized functions which only differ by metadata lookups. But it can also merge other types of functions.
It gives ~7% code size reducation for the stdlib.
There are still some open TODOs, e.g. to share common code with LLVM's MergeFunctions pass (currently much code is just copied).
Assertion failed: (NumUsePointsToFind > 0 && "There must be at least one
releasing instruction for an alloc"), function canPromoteAlloc
Revert "Fix comment for StackPromotion pass in SIL Passes"
Revert "Reapply the StackPromotion commit
0dd045ca04dcc10a33abf57f7e1b08260c4e3de1."
This reverts commit 3f4b1496bd and commit
199cfca13b.
It promotes allocations of native swift objects and array buffers to the stack if it is possible.
The SIL StackPromotion pass is the main part of the optimization. For details see comments there.
Unfortunately we need an additional LLVM pass to handle array buffers, which is not very nice.
I hope that we can get rid of it in future (again: for details see the comments in StackPromotion.cpp)
The optimization gives performance improvements in some benchmarks, mostly related to array literals:
ArrayLiteral: +12%
Combos: +16%
DictionaryLiteral: + 37%
RIPEMD: +10%
StringBuilder: +27%
StringInterpolation: +11%
And last but not least the new benchmark which is dedicated to test stack promotion:
ObjectAllocation: +52%
OptimizeARC does not only contain an optimize arc pass: the library also
includes aa. What this really is a repository of the extra passes and
infrastructure that we inject into LLVM. Thus LLVMPasses is a more descriptive
name. It also matches SILPasses.
I also taught lit how to use the new llvm-opt driver for running swift llvm
passes through opt without having to remember how to setup the dynamic swift
llvm pass dylib. You can use this in lit tests by using the substitution
%llvm-opt.
Swift SVN r21654
