Currently LLDB calls into ide::getDeclFromMangledSymbolName() to get
to this information and we would like to get rid of this call.
rdar://problem/47798056
Summary:
There are a few problems with how Swift currently emits location
information for CodeView.
1. WinDbg does not work well with column information so all column
locations must be set to zero.
2. Some instructions, e.g., ``a + b``, will emit ``@llvm.trap()``
and ``unreachable``. Those instructions should have artificial
locations, i.e., they should have a line location of zero.
3. Some instructions, e.g., ``a / b``, will emit ``unreachable``
sandwiched between other code for that instruction. This makes
WinDbg confused and it cannot decide which set of instructions
to break on. Those instructions should have the same line location
as the others.
4. There are several prologue instructions with artificial line
locations that create breaks in the linetables. Those instructions
should have valid line locations, usually at the start of the
function.
5. Case bodies have cleanup instructions with artificial line
locations unless it has a ``do`` block. Those locations should
be the last line in the case block.
Test Plan:
test/DebugInfo/basic.swift
test/DebugInfo/columns.swift
test/DebugInfo/linetable-codeview.swift
test/DebugInfo/line-directive-codeview.swift
instead of using name and decl context.
The advantages of this approach are three-fold:
- This is necessary to support inlined generic functions.
- We can retire the debugger-specific type name manfgling mode for archetypes.
- This saves 270kb of debug information in the x86_64 libSwiftCore.dylib alone.
<rdar://problem/38306256>
Note that this is only correct unless the variable uses inline
storage. This makes the majority of resilient types in Foundation work
as global variables. The correct solution would be for LLDB to poke
at the runtime to figure out whether the storage is inline or not, but
until then this is the next best thing.
rdar://problem/39722386
This commit changes how inline information is stored in SILDebugScope
from a tree to a linear chain of inlined call sites (similar to what
LLVM is using). This makes creating inlined SILDebugScopes slightly
more expensive, but makes lowering SILDebugScopes into LLVM metadata
much faster because entire inlined-at chains can now be cached. This
means that SIL is no longer preserve the inlining history (i.e., ((a
was inlined into b) was inlined into c) is represented the same as (a
was inlined into (b was inlined into c)), but this information was not
used by anyone.
On my late 2012 i7 iMac, this saves about 4 seconds when compiling the
RelWithDebInfo x86_64 swift standard library — or 40% of IRGen time.
rdar://problem/28311051
This fixes a crash while building the Swift standard library when
partial specializations are enabled.
Eventually we should get rid of needing the DeclContext in the mangled
typename at all, and this is one step towards that goal.
rdar://problem/31253373
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
The Darwin linker won't process the debug info if the source file name
is invalid so there is no point in having a fallback implemented there.
<rdar://problem/25130236>
This saves ~4 seconds of a -r --no-assertions stdlib build and lowers
the contribution of llvm::SourceMgr::getLineAndColumn() to the total
runtime from 6% to 2%.
<rdar://problem/27016577>
It is not valid LLVM IR to have a function call without a location to an
inlinable function inside a function with debug info — this makes it impossible
to construct inline information.
This patch adds an assertion and fixes up several places across IRGen where
such a situation could happen.
rdar://problem/26955467
explosion schema rather than from the debug type information and retire
a bunch of heuristics that are no longer necessary.
To enable this, this commit also includes a bugfix to debug info for
opaque data structures with the correct size and alignment information.
<rdar://problem/21470869+22707597>
This reapplies ad4f065ad6 and 7e489db9 after fixing the problem
uncovered by this commit in 5726370c1.
explosion schema rather than from the debug type information and retire
a bunch of heuristics that are no longer necessary.
To enable this, this commit also includes a bugfix to debug info for
opaque data structures with the correct size and alignment information.
<rdar://problem/21470869+22707597>
