It was only used in a few tests. Those tests now use -emit-sil instead
of -emit-silgen, with some functions marked @_transparent and a few
CHECK: lines changed now that the mandatory optimizations get to run.
Add a new warning that detects when a function will call itself
recursively on all code paths. Attempts to invoke functions like this
may cause unbounded stack growth at least or undefined behavior in the
worst cases.
The detection code is implemented as DFS for a reachable exit path in
a given SILFunction.
We want as few module passes as possible.
Function passes allow the PassManager to do its job.
e.g. it can filter certain functions that should not be applied to the
current pipeline. This will result in less work in the pass itself and
fewer pass manager related bugs.
Function passes are easier to understand and debug in the context of the
pipeline. Things like PrettyStackTrace are handled automatically.
Bisecting functionality is builtin.
Function passes are more compatible in general with inter-procedural
analysis.
Function passes are more efficient.
A single module pass in the middle of the pipeline destroys the benefit
of the rest of the pipeline uses function passes.
We run GlobalOpt multiple times in the pass pipeline but in some cases object outlining shouldn't be done too early.
Having it done in a separate pass enables to run it independently from GlobalOpt.
We run GlobalOpt multiple times in the pass pipeline but in some cases object outlining shouldn't be done too early.
Having it done in a separate pass enables to run it independently from GlobalOpt.
* rename "Name" to "Description" in the pass definition, because it's not really the pass name, but the description of a pass
* remove the getName() from Transforms (which actually returned the description of a pass)
* in debug printing, print the pass ID and not the pass description. It makes it easier to correlate the debug output to the actual pass implementation.
* remove the iteration numbering in the pass manager, because we only run a single iteration anyway.
This commit is mostly refactoring.
*) Introduce a new OptimizationMode enum and use that in SILOptions and IRGenOptions
*) Allow the optimization mode also be specified for specific SILFunctions. This is not used in this commit yet and thus still a NFC.
Also, fixes a minor bug: we didn’t run mandatory IRGen passes for functions with @_semantics("optimize.sil.never")
Recent changes that eliminated the -sil-serialize-all mode and adding this check to IRGen allow us to get rid of ExternalFunctionDefinitionsElimination and ExternalDefsToDecls passes, which are not needed anymore.
This patch implements collection and dumping of statistics about SILModules, SILFunctions and memory consumption during the execution of SIL optimization pipelines.
The following statistics can be collected:
* For SILFunctions: the number of SIL basic blocks, the number of SIL instructions, the number of SIL instructions of a specific kind, duration of a pass
* For SILModules: the number of SIL basic blocks, the number of SIL instructions, the number of SIL instructions of a specific kind, the number of SILFunctions, the amount of memory used by the compiler, duration of a pass
By default, any collection of statistics is disabled to avoid affecting compile times.
One can enable the collection of statistics and dumping of these statistics for the whole SILModule and/or for SILFunctions.
To reduce the amount of produced data, one can set thresholds in such a way that changes in the statistics are only reported if the delta between the old and the new values are at least X%. The deltas are computed as using the following formula:
Delta = (NewValue - OldValue) / OldValue
Thresholds provide a simple way to perform a simple filtering of the collected statistics during the compilation. But if there is a need for a more complex analysis of collected data (e.g. aggregation by a pipeline stage or by the type of a transformation), it is often better to dump as much data as possible into a file using e.g. -sil-stats-dump-all -sil-stats-modules -sil-stats-functions and then e.g. use the helper scripts to store the collected data into a database and then perform complex queries on it. Many kinds of analysis can be then formulated pretty easily as SQL queries.
This is a separate optimization that detects short-lived temporaries that can be eliminated.
This is necessary now that SILGen no longer performs basic RValue forwarding in some cases.
SR-5508: Performance regression in benchmarks caused by removing SILGen peephole for LoadExpr in +0 context
The problem here is that we were performing a naive negative FileCheck test for
retain/release. In certain modes, we would not have any retains/releases along
normal control paths but would have retains on unreachable paths. This test only
is trying to test if normal code paths have this issue.
To work around this issue, I created a small utility pass that prunes all
non-unreachable instructions from blocks with an unreachable terminator. This is
useful functionality in general when analyzing SIL since often times one will
have large fatal error blocks that disguise the true behavior of the
function. In this specific case, I just pipe in the normal sil output and run it
through sil-opt. sil-opt then runs just the utility pass and I then FileCheck
that sil-opt output.
rdar://30181104
A pass has an ID (C++ identifier), Tag (shell identifier),
and Name (human identifier).
Command line options that identify passes should obviously be compatibile with
with the pass' command line identifier. This is also what the user is used to
typing for the -debug-only option.
In raw SIL, access markers are unconditionally retained. In canonical SIL,
markers are still removed prior to optimization.
A new flag, -sil-optimized-access-markers, allows testing access markers in
optimized builds, but it is not yet fully supported.
Add an interprocedural SIL analysis pass that summarizes the accesses that
closures make on their @inout_aliasable captures. This will be used to
statically enforce exclusivity for calls to functions that take noescape
closures.
The analysis summarizes the accesses on each argument independently and
uses the BottomUpIPAnalysis utility class to iterate to a fixed point when
there are cycles in the call graph.
For now, the analysis is not stored-property-sensitive -- that will come in a
later commit.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
I put in a simple fixup pass (MarkUninitializedFixup) for staging purposes. I
don't expect it to be in tree long. I just did not feel comfortable fixing up in
1 commit all of the passes up to DI.
rdar://31521023
Add a diagnostic pass that emits errors when a violation of the "Law of
Exclusivity" is detected at compile time. The Law of Exclusivity requires
that the access duration of any access to an address not overlap
with an access to the same address unless both accesses are reads.
This pass relies on 'begin_access' and 'end_access' SIL instruction
markers inserted by SILGen to determine when an access to an address begins and
ends. It models the in-progress accesses with a map from storage locations to
the counts of read and write-like accesses in progress for that location.
At some point, pass definitions were heavily macro-ized. Pass
descriptive names were added in two places. This is not only redundant
but a source of confusion. You could waste a lot of time grepping for
the wrong string. I removed all the getName() overrides which, at
around 90 passes, was a fairly significant amount of code bloat.
Any pass that we want to be able to invoke by name from a tool
(sil-opt) or pipeline plan *should* have unique type name, enum value,
commend-line string, and name string. I removed a comment about the
various inliner passes that contradicted that.
Side note: We should be consistent with the policy that a pass is
identified by its type. We have a couple passes, LICM and CSE, which
currently violate that convention.
I improved all of the pass names so they are minimal but fully descriptive.
The PASS macros contained wordy, unhelpful descriptions, which served
no functional purpose. Those descriptions are permanently preseved in
git history. If anyone thinks they contain useful information, then
they should be added to the *definition* of the pass (where passes are
actually described).
Long-winded pass comments have no place in Passes.def. The purpose of
those macros is to associate a unique type name, enum value,
command-line-option name, and pretty name with each pass for tooling
purposes. Any one of those entities needs to be sufficient for looking
up the others. That's not where anyone should look read a description
of the pass.
I am going to run it very early and use it to ensure that extra copies due to my
refactoring of SILGenPattern do not cause COW copies to be introduced.
For now, it does a very simple optimization, namely, it eliminates a copy_value,
with only a destroy_value user on a guaranteed parameter.
It is now disabled behind a flag.
There are now separate functions for function addition and deletion instead of InvalidationKind::Function.
Also, there is a new function for witness/vtable invalidations.
rdar://problem/29311657
Print the SIL function body on an assert. Recovering the SIL code is the
critical path for pretty much any SIL development. The only alternative is
rebuilding the library with string matching or building a debug compiler and
hoping lldb works. The standard library takes a very long time to build with a
debug compiler.
Hoist alloc_stack instructions of 'generic' or resilient type to the entry
block. At the same time also perform a very simple stack coloring analysis.
This does not use a true liveness-analysis yet but rather employs some simple
conservative checks to see whether the live ranges of two alloc_stacks might
interfere.
AllocStackHoisting is an IRGen SIL pass. This allows for using IRGen's type
lowering information. Furthermore, hoisting and merging the alloc_stack
instructions this late does not interfere with SIL optimizations because the
resulting SIL never gets serialized.
This pipeline is run as part of IRGen and has access to the IRGenModule.
Passes that run as part of this pipeline can query for the IRGenModule.
We will use it for the AllocStackHoisting pass. It wants to know if a type is of
non-fixed size.
To break the cyclic dependency between IRGen -> SILOptimizer -> IRGen that would
arise from the SILPassManager having to know about the createIRGENPASS()
function IRGen passes instead of exposing this function dynamically have to add
themselves to the pass manager.
This pass works by blowing up if it finds an apply that calls a function
specified via the cl command line option 'bug-reducer-tester-target-func'. This
makes it easy to test sil-bug-reducer.
We also either remove or make private the addPass* functions on SILPassManager,
so the only way to execute passes via SILPassManager is by creating a
SILPassPipelinePlan. This beyond adding uniformity ensures that we always
resetAndRemoveTransformations properly after a pipeline is run.
