* Replace 'Fast' with 'Unchecked' everywhere.
* Update the help text to specify DisableReplacement rather than
Replacement and to document Unchecked.
* Simplify tests slightly and add a tests for Unchecked.
This removes the -use-native-super-method flag and turns on dynamic
dispatch for native method invocations on super by default.
rdar://problem/22749732
Use the `super_method` instruction for non-final `func` and `class func`
declarations in native Swift classes. Previously, we would always emit
a static `function_ref` for these, which prevents resilient dynamic
dispatch.
This is hidden behind a -use-native-super-dispatch flag while I
survey the effects on devirtualization and stack promotion. When
that's figured out, I'll add more tests and update test cases that
still assume static dispatch.
rdar://problem/22749732
This patch implements the pre-specialization for the most popular generic types from the standard library. If there are invocations of generic functions from the standard library in the user-code and the compiler can find the specialized, optimized versions of these functions, then calls of generic functions are simply replaced by the calls of the specialized functions.
This feature is supposed to be used with -Onone to produce much faster (e.g. 5x-10x faster) executables in debug builds without impacting the compile time. In fact, the compile-time is even improved, because IRGen has less work to do. The feature can be considered a light-weight version of the -Odebug, because pre-specialization is limited in scope, but does not have a potentially negative compile-time impact compared to -Odebug. It is planned to enable it by default in the future.
This feature is disabled by default for the time being. It can be enabled by using a hidden flag: -Xllvm -use-prespecialized.
The implementation consists of two logical steps:
- When the standard library is being built, we force a creation of specializations for the most popular generic types from the stdlib, e.g. Arrays of integer and floating point types, Range<Int>, etc. The list of specializations is not fixed and can be easily altered by editing the Prespecialized.swift file, which is responsible for forcing the specialization of generic types (this is simple solution for now, until we have a proper annotation to indicate which specializations of a given generic type or function we want to generate by means of the pre-specialization). These specializations are then optimized and preserved in the stdlib dylib and in the Swift SIL module. The size increase of the stdlib due to creation of pre-specializations is currently about 3%-7%.
- When a user-code is being compiled with -Onone, the compiler would run a generic specializer over the user-code. If there are calls of generic functions from the standard library, the specializer would check if there is an existing specialization matching these invocations. If such a specialization is found, the original call is replaced by the call of this more efficient specialized version.
Swift SVN r30309
The value is set based on the -O command-line option. It is generally useful if SIL optimization passes can check the current optimization level.
A couple of subsequent commits are going to make use of this information.
Swift SVN r29653
I was always confused by the inconsistency of -sil-print-all and the other -sil-print options.
So I thought it would be a good idea to make -sil-print-all also an llvm option.
Together with some other internal options which are only used in the pass manager.
Swift SVN r29365
The only caveat is that:
1. We do not properly recognize when we have a let binding and we
perform a guaranteed dynamic call. In such a case, we add an extra
retain, release pair around the call. In order to get that case I will
need to refactor some code in Callee. I want to make this change, but
not at the expense of getting the rest of this work in.
2. Some of the protocol witness thunks generated have unnecessary
retains or releases in a similar manner.
But this is a good first step.
I am going to send a large follow up email with all of the relevant results, so
I can let the bots chew on this a little bit.
rdar://19933044
Swift SVN r27241
This adds the -profile-coverage-mapping option to swift, and teaches
SILGenProfiling to generate mappings from source ranges to counters.
Swift SVN r25266
This adds the -profile-generate flag, which enables LLVM's
instrumentation based profiling. It implements the instrumentation
for basic control flow, such as if statements, loops, and closures.
Swift SVN r25155
Main changes:
*) Instruction costs are not counted for blocks which are dead after inlining
*) Terminator instructions which get constant after inlining increase the threshold
*) Calls inside loops increase the threshold
In theory this should be a step towards making the performance not so dependent on the inlining heuristic.
But I must admit that I still did some fine tuning of all the parameters to get the best results.
Improvements in the benchmarks:
-O:
Chars: +11%
CommonMarkRender: +11%
DollarReduce: +22%
ForLoops: +22%
Forest: +10%
HeapSort: +36%
ImageProc: +14%
StrCat: +14%
StrComplexWalk: +70%
StrToInt: +11%
StringWalk: +99%
-Ounchecked:
Ary: +40%
Ary2: +30%
EditDistance: +22%
Forest: +18%
HeapSort: +50%
Histogram: +11%
StrCat: +12%
StrComplexWalk: +63%
StrSplitter: +11%
StrToInt: +17%
StringWalk: +75%
Regressions (I will file radars for them):
-Ounchecked:
PolymorphicCalls: -21%
QuickSort: -22%
Rectangles: -12%
Code size of the PerfTests_O decreased by 8%
Code size of the PerfTests_Ounchecked increased by 1%
Swift SVN r24801
If a subclass overrides methods with variance in the optionality of non-class-type members, emit a thunk to handle wrapping more optional parameters or results and force-unwrapping any IUO parameters made non-optional in the derived. For this to be useful, we need IRGen to finally pay attention to SILVTables, but this is a step on the way to fixing rdar://problem/19321484.
Swift SVN r24705
This flag enables one to specify a json file that expresses a specific
pipeline in the following format:
[
[
"$PASS_MANAGER_ID",
"run_n_times"|"run_to_fixed_point",
$NUM_ITERATIONS,
"$PASS1", "$PASS2", ...
],
...
]
This will make it easier to experiment with different pass pipelines by
allowing:
1. Automatic generation of pass pipelines without needing to recompile
the compiler itself.
2. Simple scripting of pass pipelines via the json meta language.
3. Enabling the easy expression and reproducability of a specific
pipeline ordering via radar.
In the next commit I will provide a python library for the generation of these
json files with a few types of pipeline generators already created.
Swift SVN r24055
This does not have any tests since I am going to start going through SILGen
tests and updating them for guaranteed self as the appropriate tests.
*NOTE* There is more work to be done in terms of thunks, but the basic
functionality is done.
rdar://15729033
Swift SVN r23653
This currently handles owned -> guaranteed argument conversion and dead argument
elimination.
RecursiveOwnedParameter||90.0%
ClassArrayGetter|||||||||23.3%
Life|||||||||||||||||||||16.7%
Prims||||||||||||||||||||11.2%
StringWalk|||||||||||||||5.7%
The next step is to implement SROA and address -> value optimizations.
rdar://16917049
Swift SVN r23023
Revert "For debugging purposes allow passes to stop any more passes from running by calling PassManager::stopRunning()."
This reverts commit r20604.
This reverts commit r20606.
This was some debugging code that snuck in.
Swift SVN r20615
This will enable via the -print-stats function the ability to quickly
find out the final count of various forms of instructions. My intention
is to use this to count retains and releases.
Swift SVN r18946
This reverts commit r17979. This causes a regression on Phonebook sort
due to it changing inlining characteristics which causes us to reference
certain functions from the stdlib dylib (which have asserts).
If Arnold's specialization code gets in I will recommit this.
Swift SVN r17986
Currently we attempt to simulate LLVM's inlining cost model. Due to the
Swift optimizer being strictly more conservative with the inlining cost
model due to swift not having as many arithmetic simplifications (for
example), the swift level cost should always be greater than or equal to
the LLVM's cost model.
Given the aforementioned paragraph, it makes sense to at least match
LLVM's cost inline threshold given we are "simulating" it.
Swift SVN r17979
No options should be changed because of the absence of a flag. This is
necessary for clients like LLDB which may have an initial set of options
that differs from the usual set.
Part of <rdar://problem/16776705>
Swift SVN r17819
We want to support three configurations:
* Debug (-Onone, -O0): user assertions, library precondition checks, runtime
checks enabled and verbose.
* Release (-O): library precondition checks, runtime checks enabled but succinct
(trap).
* Fast (-Ofast): all checks off.
The _isFast predicate will allow to write standard library functions to support
this plan. This commit changes fatal() to differentiate between the three modes.
Support for rdar://16477198
Swift SVN r17697
This patch adds support for a builtin function assert_configuration that is
replaced by constant progpagation by an appropriate value dependent on a compile
time setting. This replacement can also be disabled when serializing sil for a
library.
Using this mechanism we implement assertions that can be disabled (or whose
behavior changes) depending on compile time build settings (Debug, Release,
DisableReplacement).
In the standard library we can now write one assert function that uses this
builtin function to provide different compile time selectable runtime behavior.
Example
Assert.swift:
@transparent
func assert<T : LogicValue>(
condition: @auto_closure () -> T, message: StaticString = StaticString(),
// Do not supply these parameters explicitly; they will be filled in
// by the compiler and aren't even present when asserts are disabled
file: StaticString = __FILE__, line: UWord = __LINE__
) {
// Only in debug mode.
if _isDebug() {
assert(condition().getLogicValue(), message, file, line)
}
}
AssertCommon.swift:
@transparent
func _isDebug() -> Bool {
return Int32(Builtin.assert_configuration()) == 0;
}
rdar://16458612
Swift SVN r16472
