Recent versions of LLDB can deal with line 0 locations much better and
due to a subtle bug in the heuristic instructions immediately following
the prologue could end up without debug locations which can cause serious
problems for the LLVM inliner when constructing inline debug scope info.
<rdar://problem/24394944>
Correct format:
```
//===--- Name of file - Description ----------------------------*- Lang -*-===//
```
Notes:
* Comment line should be exactly 80 chars.
* Padding: Pad with dashes after "Description" to reach 80 chars.
* "Name of file", "Description" and "Lang" are all optional.
* In case of missing "Lang": drop the "-*-" markers.
* In case of missing space: drop one, two or three dashes before "Name of file".
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
When computing the locations for local indirect enums, we could enter
an infinite loop if the first field is a recursive reference.
Just bail out of the field-splitting logic if we encounter an indirect
case. More work might be needed if indirect enums get exploded.
rdar://problem/21927941
Swift SVN r30717
MDModule was a bitcode-incompatible internal-only extension that has
since been replaced with a blessed IR node on trunk.
<rdar://problem/20965932> Upstream DIModule and support it in clang-700, swiftlang-700, and lldb-700
Swift SVN r29832
We still don't actually handle these correctly, but at least
we have sensible information for them now.
Also, remember that we're working with canonical generic
signatures in more places.
Swift SVN r27388
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
at -Onone. This is currently turned off by default because it
also reports false positives, but it is an incredibly useful mechanism
to find linetable bugs.
Swift SVN r22738
info for them and generally clean up the inline scope handling a bit.
Fix the debug scope handling for all clients of SILCloner, especially
the SIL-level spezializers and inliners.
This also adds a ton of additional assertions that will ensure that
future optimization passes won't mess with the debug info in a way that
could confuse the LLVM backend.
Swift SVN r18984
Mandatory-inlined (aka transparent functions) are still treated as if they
had the location and scope of the call site. <rdar://problem/14845844>
Support inline scopes once we have an optimizing SIL-based inliner
Patch by Adrian Prantl.
Swift SVN r18835
than once (at least as far as IRGenDebugInfo is concerned).
No new testcases, but it comes with new assertions.
Part of <rdar://problem/15283227> A crash in llvm's getFnAttributes when IRGen is called more than once.
Swift SVN r18214
tuples and structs that are passed to a function by value.
<rdar://problem/15928331> Need to support DW_OP_piece for multi-Value variables/arguments
<rdar://problem/16599747> Variables not displayed at all in SwiftDemo02b_Closure (back again)
Swift SVN r17923
for types where possible.
We use the DICompositeType's UniqueIdentifier field to store the mangled
name, the name field to store the base name and Apple-llvm will emit the
unique identifier as DW_AT_name if RunTimeLang == Swift. This way the
metadata format is compatible between swift and non-Apple clang.
As bonus, we get mangled-name-based type uniquing for swift.
<rdar://problem/16303510> apple-types accelerator table should include basename for swift types
Swift SVN r16665
modules on LLVM/trunk.
This should fix most open module related bugs and in a way that is
compatible with upstream LLVM.
<rdar://problem/16539726> Fix debug info for modules after LLVM r205685
<rdar://problem/16504765> Emit DW_TAG_namespace entry for the current module into DWARF
Swift SVN r16086
