Tiny start-up time optimization noticed while looking at how we do
PrettyStackTraceProgram. Also add PrettyStackTraceProgram to a few
more of our testing tools, via the new PROGRAM_START macro.
For now these are underscored attributes, i.e. compiler internal attributes:
@_optimize(speed)
@_optimize(size)
@_optimize(none)
Those attributes override the command-line specified optimization mode for a specific function.
The @_optimize(none) attribute is equivalent to the already existing @_semantics("optimize.sil.never") attribute
The default when creating a target machine should be to leave the
code model unspecified (at least that is the default argument value).
The previous change (7526d07525) also missed one place that needed
to be updated.
The main action here is to sink the creation of the installation rule for all of
the swift host tools into this API. In a latter commit, I will use this API to
create include and build rules for add_swift_host_tool.
All of these cases seem to need the symbols from LLVM's new CodeView library to
link.
The specific executables are:
1. Swift Driver.
2. SIL Extract.
3. SIL Opt.
4. Swift IDE Test.
5. Swift LLVM Opt.
6. LLDB Module Import Test
LLVM SVN r276687 ported the SymbolRewriter pass to the new PM. This results in
the constructor being renamed. Adjust the swift-llvm-opt tool accordingly.
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).
Swift relies on this for now. So create our own. This makes more sense
than trying to add back in the API (which is dead besides the c api) or
use the c api itself. We should probably consider not using a global
context like this.
All of these cases seem to need the symbols from LLVM's new CodeView library to
link.
The specific executables are:
1. Swift Driver.
2. SIL Extract.
3. SIL Opt.
4. Swift IDE Test.
5. Swift LLVM Opt.
6. LLDB Module Import Test
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%
Now that one can not use analysis groups anymore on LLVM, we were given two
choices. Reinsert that dynamicism so we could via opt -load add in analyses /or/
just create our own version of opt. I decided to go with the later since it
enables us to simulate how IRGen sets up the LLVM pass pipeline exactly,
something we were unable to do before.
This also sets us up for whenever we need to respond to the new pass manager.
Swift SVN r32808
