Adds sections `__TEXT,__swift_as_entry`, and `__TEXT,__swift_as_ret` that
contain relative pointers to async functlets modelling async function entries,
and function returns, respectively.
Emission of the sections can be trigger with the frontend option
`-Xfrontend -enable-async-frame-push-pop-metadata`.
This is done by:
* IRGen adding a `async_entry` function attribute to async functions.
* LLVM's coroutine splitting identifying continuation funclets that
model the return from an async function call by adding the function
attribute `async_ret`. (see #llvm-project/pull/9204)
* An LLVM pass that keys off these two function attribute and emits the
metadata into the above mention sections.
rdar://134460666
This has a few nice benefits:
1. The splitting happens after LLVM optimizations have run. This ensures that
LLVM will not join these blocks no matter what! The author of this commit has
found that in certain cases LLVM does this even at -Onone. By running this late,
we get the benefit we are looking for: working around the bad SelectionDAG
behavior.
2. This block splitting is just a workaround for the above mentioned unfortunate
SelectionDAG behavior. By doing this when we remove the workaround, we will not
have to update SIL level tests... instead we will just remove a small LLVM pass.
Some additional notes:
1. Only moved values will ever have llvm.dbg.addr emitted today, so we do not
have to worry about this impacting the rest of the language.
2. The pass's behavior is tested at the IR level by move_function_dbginfo.swift.
Otherwise we set it on all targets/languages in a subdirectory (I forgot if it
propagates up). Regardless, this type of viral stuff is something we want to
move away from since it creates a code that is a "forall" piece of code rather
than a piece of code that only effects a single target.
I also conditionalized the actual definitions being added on the compiled file's
language being C,CXX,OBJC,OBJCXX since as we add Swift sources to the host side
of the compiler, we will not want these flags to propagate to Swift sources.
A follow-up PR adds a flag to control an inline namespace that allows
symbols in libDemangling to be distinguished between the runtime and
the compiler. These dependencies ensure that the flag is plumbed
through for inclusions of Demangling headers that aren't already
covered by existing `target_link_libraries`.
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.
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.
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
