This ireapplies commit 255c52de9f.
Original commit message:
Serialize debug scope and location info in the SIL assembler language.
At the moment it is only possible to test the effects that SIL
optimization passes have on debug information by observing the
effects of a full .swift -> LLVM IR compilation. This change enable us
to write targeted testcases for single SIL optimization passes.
The new syntax is as follows:
sil-scope-ref ::= 'scope' [0-9]+
sil-scope ::= 'sil_scope' [0-9]+ '{'
sil-loc
'parent' scope-parent
('inlined_at' sil-scope-ref )?
'}'
scope-parent ::= sil-function-name ':' sil-type
scope-parent ::= sil-scope-ref
sil-loc ::= 'loc' string-literal ':' [0-9]+ ':' [0-9]+
Each instruction may have a debug location and a SIL scope reference
at the end. Debug locations consist of a filename, a line number, and
a column number. If the debug location is omitted, it defaults to the
location in the SIL source file. SIL scopes describe the position
inside the lexical scope structure that the Swift expression a SIL
instruction was generated from had originally. SIL scopes also hold
inlining information.
<rdar://problem/22706994>
At the moment it is only possible to test the effects that SIL
optimization passes have on debug information by observing the
effects of a full .swift -> LLVM IR compilation. This change enable us
to write targeted testcases for single SIL optimization passes.
The new syntax is as follows:
sil-scope-ref ::= 'scope' [0-9]+
sil-scope ::= 'sil_scope' [0-9]+ '{'
sil-loc
'parent' scope-parent
('inlined_at' sil-scope-ref )?
'}'
scope-parent ::= sil-function-name ':' sil-type
scope-parent ::= sil-scope-ref
sil-loc ::= 'loc' string-literal ':' [0-9]+ ':' [0-9]+
Each instruction may have a debug location and a SIL scope reference
at the end. Debug locations consist of a filename, a line number, and
a column number. If the debug location is omitted, it defaults to the
location in the SIL source file. SIL scopes describe the position
inside the lexical scope structure that the Swift expression a SIL
instruction was generated from had originally. SIL scopes also hold
inlining information.
<rdar://problem/22706994>
Use malloc/free for allocating/freeing SIL instructions instead of using the BumpPtrAllocator. This allows for memory reuse and significantly reduces the memory footprint of the compiler.
For example, a peak memory usage during a compilation of the standard library and StdlibUnitTest is reduced by 25%-30%. The performance of the compiler seems to be not affected by this change, i.e. no slowdown is measured.
The use-after-free issues reported by build bots are fixed now.
rdar://23303031
This commit adds the basic support for delete notification handlers. The SIL
Module is notified every time an instruction is deleted. The module will forward
notification messages to users who ask to be notified. The motivation for this
work is described in the upcoming commit to OptimizerDesign.md.
The drivers for this change are providing a simpler API to SIL pass
authors, having a more efficient of the in-memory representation,
and ruling out an entire class of common bugs that usually result
in hard-to-debug backend crashes.
Summary
-------
SILInstruction
Old New
+---------------+ +------------------+ +-----------------+
|SILInstruction | |SILInstruction | |SILDebugLocation |
+---------------+ +------------------+ +-----------------+
| ... | | ... | | ... |
|SILLocation | |SILDebugLocation *| -> |SILLocation |
|SILDebugScope *| +------------------+ |SILDebugScope * |
+---------------+ +-----------------+
We’re introducing a new class SILDebugLocation which represents the
combination of a SILLocation and a SILDebugScope.
Instead of storing an inline SILLocation and a SILDebugScope pointer,
SILInstruction now only has one SILDebugLocation pointer. The APIs of
SILBuilder and SILDebugLocation guarantees that every SILInstruction
has a nonempty SILDebugScope.
Developer-visible changes include:
SILBuilder
----------
In the old design SILBuilder populated the InsertedInstrs list to
allow setting the debug scopes of all built instructions in bulk
at the very end (as the responsibility of the user). In the new design,
SILBuilder now carries a "current debug scope" state and immediately
sets the debug scope when an instruction is inserted.
This fixes a use-after-free issue with with SIL passes that delete
instructions before destroying the SILBuilder that created them.
Because of this, SILBuilderWithScopes no longer needs to be a template,
which simplifies its call sites.
SILInstruction
--------------
It is neither possible or necessary to manually call setDebugScope()
on a SILInstruction any more. The function still exists as a private
method, but is only used when splicing instructions from one function
to another.
Efficiency
----------
In addition to dropping 20 bytes from each SILInstruction,
SILDebugLocations are now allocated in the SILModule's bump pointer
allocator and are uniqued by SILBuilder. Unfortunately repeat compiles
of the standard library already vary by about 5% so I couldn’t yet
produce reliable numbers for how much this saves overall.
rdar://problem/22017421
This reverts commit r32359.
I'll look into doing fine-grained rebuilds of portions of the call graph
after some other changes go in that will make that more reasonable to
do.
Swift SVN r32379
Call back to the SILModule to notify of instructions being inserted or
removed from basic blocks.
The intent is to use this to notify the call graph (if one exists and
the module knows about it). We can then use these notifications to
automatically update the call graph.
Swift SVN r32359
Move the implementation of SILBasicBlock::splitBasicBlockAndBranch into
CFG's util function swift::splitBasicBlockAndBranch since it's the only
user, and update the latter to take a SILBuilder and use it to create
the branch to the split-off block.
Swift SVN r32128
The cloned abstract variables may end up having different types
so they need to be distinct from the originals.
This fixes an crash/assertion in the LLVM backend.
rdar://problem/21109015
Swift SVN r29184
the debug scope of each instruction to be the debug scope of the new
function.
This will be tested by the functionality in function signature opts.
Swift SVN r22553
constructor in SILBasicBlock::createArgument.
By default the argument is nullptr so any place that currently does not
need to pass in the ValueDecl will not need to be updated given the new
behavior.
Swift SVN r22379
SILArgument::getIncomingValues() takes in an out array parameter and attempts to
gather up all values from the SILArguments parents predecessors whose value the
SILArgument could take on.
This will let me refactor the single predecessor handling code to also handle
multiple predecessors in a simple way.
Swift SVN r21864
In a loop like this:
var j = 2
for var i = 0; i < 100; ++i {
j += 3
}
it will completely eliminate j.
It does not yet support rewriting conditional branches as unconditional
branches in the cases where only empty blocks are control dependent on
an edge. Once this support is added, it will also completely eliminate
the loop itself.
Swift SVN r18615
If we have BB args that are only used in a struct/tuple extract, and
that are generated in each predecessor with a struct/tuple instruction,
retype the BB arg and replace the argument with what would have been the
extracted value.
This provides more opportunties for jump threading to kick in.
Swift SVN r16509
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
