First, it fixes a crash where the eliminated function is still referenced.
This shows up if two equivalent self-recursive functions are merged and those functions are internal.
Fixes SR-4514, rdar://problem/31479425
Second, it avoids creating a not needed parameter for really equivalent self recursive functions.
Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
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 the FunctionComparator is a separate utility in LLVM, the SwiftMergeFunctions pass can use it instead of duplicating the code.
This is pure refactoring. NFC.
Fixed for the difference of Cygwin with other Windows variants (MSVC,
Itanium, MinGW).
- The platform name is renamed to "cygwin" from "windows" which is used
for searching the standard libraries.
- The consideration for DLL storage class (DllExport/DllImport) is not
required for Cygwin and MinGW. There is no problem when linking in
these environment.
- Cygwin should use large memory model as default.(This may be changed
if someone ports to 32bit)
- Cygwin and MinGW should use the autolink feature in the sameway of
Linux due to the linker's limit.
For semantic ARC I need to add an endBorrow entrypoint that will be removed by
ARCContract.cpp. In the process I am doing a little bit of cleanup.
In this commit, I only use this to generate the enum RT_Kind in LLVMARCOpts.h. I
verified it was the same using a diff tool. I am going to do further updates in
subsequent commits to make the diff easy to see.
When constructing the body of the merged function, the internal function is
given internal linkage always. It is only accessible through the adjusting
thunks which retain the original DLL storage. Ensure that we reset the DLL
storage which it inherited from the first function.
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.
Add initial support for modelling DLL Storage semantics for global values. This
is needed to support the indirect addressing mechanism used on Windows.
This updates MergeFunctions with a custom ordering comparator for the
AtomicOrdering. This is needed after a LLVM API change which changes the
AtomicOrdering to a strongly typed enumeration.
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.
