Cleanup includes: DebugInfo & CodeGen

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332

[Dwarf] Optimize getOrCreateSourceID() for repeated calls on same file (NFCI)

DwarfCompileUnit::getOrCreateSourceID() is often called many times
in sequence with the same DIFile. This is currently v

[Dwarf] Optimize getOrCreateSourceID() for repeated calls on same file (NFCI)

DwarfCompileUnit::getOrCreateSourceID() is often called many times
in sequence with the same DIFile. This is currently very expensive,
because it involves creating a string from directory and file name
and looking it up in a string map. This patch remembers the last
DIFile and its ID and directly returns that.

This gives a geomean -1.3% compile-time improvement on CTMark O0-g.

Differential Revision: https://reviews.llvm.org/D118041

show more ...

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches

Try to revert D113741 once again.

This also reverts 0ac75e82fff93a80ca401d3db3541e8d1d9098f

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches

Try to revert D113741 once again.

This also reverts 0ac75e82fff93a80ca401d3db3541e8d1d9098f9 (D114705)
as it causes LLDB's lldb-api.lang/cpp/nsimport.TestCppNsImport.py test
failure w/o D113741.

This reverts commit f9607d45f399e2afc39ec16222ea68b4e0831564.

Differential Revision: https://reviews.llvm.org/D116225

show more ...

Revert "Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches"

This has broke following LLDB buildbots:

https://lab.llvm.org/buildbot/#/builders/

Revert "Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches"

This has broke following LLDB buildbots:

https://lab.llvm.org/buildbot/#/builders/17/builds/14984
https://lab.llvm.org/buildbot/#/builders/96/builds/15928
https://lab.llvm.org/buildbot/#/builders/68/builds/23600

This reverts commit 62a6b9e9ab3eb778111e90a34fee1e6a7c64db8a.

show more ...

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches

This patch causes invalid DWARF to be generated in some cases of LTO +
Split DWARF - follow-

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches

This patch causes invalid DWARF to be generated in some cases of LTO +
Split DWARF - follow-up on the original review thread (D113741) contains
further detail and test cases.

This reverts commit 75b622a7959479ccdb758ebe0973061b7b4fcacd.
This reverts commit b6ccca217c35a95b8c2a337a7801b37cb23dbae2.
This reverts commit 514d37441918dd04a2cd4f35c08959d7c3ff096d.

show more ...

Reland [DwarfDebug] Support emitting function-local declaration for a lexical block

This is another attempt to make function-local declarations
(like static variables, structs/classes and other) be

Reland [DwarfDebug] Support emitting function-local declaration for a lexical block

This is another attempt to make function-local declarations
(like static variables, structs/classes and other) be correctly
emitted within a lexical (bracketed) block.

Fixes https://bugs.llvm.org/show_bug.cgi?id=19238.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D113741

show more ...

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block"

This reverts commits
* ee691970a9a85470948ada623c31f0ab8773617c (D113741),
* 79d3132998b2828be8f7d2ec411f91fb11b

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block"

This reverts commits
* ee691970a9a85470948ada623c31f0ab8773617c (D113741),
* 79d3132998b2828be8f7d2ec411f91fb11b3e01f (D114705)

due to lldb and dexter test failures.

show more ...

[DwarfDebug] Support emitting function-local declaration for a lexical block

This is another attempt to make function-local declarations
(like static variables, structs/classes and other) be correct

[DwarfDebug] Support emitting function-local declaration for a lexical block

This is another attempt to make function-local declarations
(like static variables, structs/classes and other) be correctly
emitted within a lexical (bracketed) block.

Fixes https://bugs.llvm.org/show_bug.cgi?id=19238.

Differential Revision: https://reviews.llvm.org/D113741

show more ...

[DwarfCompileUnit] Set parent DIE right after creating a local entity

No functional changes intended.

Before this patch DwarfCompileUnit::createScopeChildrenDIE() and
DwarfCompileUnit::createAndAdd

[DwarfCompileUnit] Set parent DIE right after creating a local entity

No functional changes intended.

Before this patch DwarfCompileUnit::createScopeChildrenDIE() and
DwarfCompileUnit::createAndAddScopeChildrenDIE() used to emit child subtrees
and then when all the children get created, attach them to a parent scope DIE.
However, when a DIE doesn't have a parent, all the requests for its unit DIE
fail.

Currently, this is not a big issue since it isn't usually needed to know unit DIE
for a local (function-scoped) entity. But once we introduce lexical blocks as
a valid scope for global variables (static locals) and type DIEs, any requests
for a unit DIE need to be guarded against local scope due to the potential
absence of the DIE's parent.

To avoid the aforementioned issue, this patch refactors a few DwarfCompileUnit
methods to support the idea of attaching a DIE to its parent as close to the
creation of this DIE as possible.

Reviewed By: ellis

Differential Revision: https://reviews.llvm.org/D114350

show more ...

[DWARF] Revert sharing subprograms across CUs

This patch is a revert of e08f205f5c2c. In that patch, DW_TAG_subprograms
were permitted to be referenced across CU boundaries, to improve stack
trace c

[DWARF] Revert sharing subprograms across CUs

This patch is a revert of e08f205f5c2c. In that patch, DW_TAG_subprograms
were permitted to be referenced across CU boundaries, to improve stack
trace construction using call site information. Unfortunately, as
documented in PR48790, the way that subprograms are "owned" by dwarf units
is sufficiently complicated that subprograms end up in unexpected units,
invalidating cross-unit references.

There's no obvious way to easily fix this, and several attempts have
failed. Revert this to ensure correct DWARF is always emitted.

Three tests change in addition to the reversion, but they're all very
light alterations.

Differential Revision: https://reviews.llvm.org/D107076

show more ...

[DebugInfo] Fix emitting DWARF64 compilation units (5/19).

The patch also adds a method to choose an appropriate DWARF form
to represent section offsets according to the version and the format
of pr

[DebugInfo] Fix emitting DWARF64 compilation units (5/19).

The patch also adds a method to choose an appropriate DWARF form
to represent section offsets according to the version and the format
of producing debug info.

Differential Revision: https://reviews.llvm.org/D87014

show more ...

[DebugInfo] Fix initialization of DwarfCompileUnit::LabelBegin.

This also fixes the condition in the assertion in
DwarfCompileUnit::getLabelBegin() because it checked something unrelated
to the retu

[DebugInfo] Fix initialization of DwarfCompileUnit::LabelBegin.

This also fixes the condition in the assertion in
DwarfCompileUnit::getLabelBegin() because it checked something unrelated
to the returned value.

Differential Revision: https://reviews.llvm.org/D85437

show more ...

DwarfCompileUnit.cpp - remove duplicate includes that already exist in DwarfCompileUnit.h. NFC.

Also remove DIE.h include from DwarfCompileUnit.h and replace with forward declarations.

[DebugInfo]: Allow DwarfCompileUnit to have line table symbol

Previously line table symbol was represented as `DIE::value_iterator`
inside `DwarfCompileUnit` and subsequent function `intStmtList`
wa

[DebugInfo]: Allow DwarfCompileUnit to have line table symbol

Previously line table symbol was represented as `DIE::value_iterator`
inside `DwarfCompileUnit` and subsequent function `intStmtList`
was used to create a local `MCSymbol` to initialize it.

This patch removes `DIE::value_iterator` from `DwarfCompileUnit`
and intoduce `MCSymbol` for representing this units symbol for
`debug_line` section. As a result `applyStmtList` is also modified
to utilize this. Further more a helper function `getLineTableStartSym`
is also introduced to get this symbol, this would be used by clients
which need to access this line table, i.e `debug_macro`.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D77489

show more ...

[DWARF] Emit DW_AT_call_pc for tail calls

Record the address of a tail-calling branch instruction within its call
site entry using DW_AT_call_pc. This allows a debugger to determine the
address to u

[DWARF] Emit DW_AT_call_pc for tail calls

Record the address of a tail-calling branch instruction within its call
site entry using DW_AT_call_pc. This allows a debugger to determine the
address to use when creating aritificial frames.

This creates an extra attribute + relocation at tail call sites, which
constitute 3-5% of all call sites in xnu/clang respectively.

rdar://60307600

Differential Revision: https://reviews.llvm.org/D76336

show more ...

Reland (again): [DWARF] Allow cross-CU references of subprogram definitions

This is a revert-of-revert (i.e. this reverts commit 802bec89, which
itself reverted fa4701e1 and 79daafc9) with a fix fol

Reland (again): [DWARF] Allow cross-CU references of subprogram definitions

This is a revert-of-revert (i.e. this reverts commit 802bec89, which
itself reverted fa4701e1 and 79daafc9) with a fix folded in. The problem
was that call site tags weren't emitted properly when LTO was enabled
along with split-dwarf. This required a minor fix. I've added a reduced
test case in test/DebugInfo/X86/fission-call-site.ll.

Original commit message:

This allows a call site tag in CU A to reference a callee DIE in CU B
without resorting to creating an incomplete duplicate DIE for the callee
inside of CU A.

We already allow cross-CU references of subprogram declarations, so it
doesn't seem like definitions ought to be special.

This improves entry value evaluation and tail call frame synthesis in
the LTO setting. During LTO, it's common for cross-module inlining to
produce a call in some CU A where the callee resides in a different CU,
and there is no declaration subprogram for the callee anywhere. In this
case llvm would (unnecessarily, I think) emit an empty DW_TAG_subprogram
in order to fill in the call site tag. That empty 'definition' defeats
entry value evaluation etc., because the debugger can't figure out what
it means.

As a follow-up, maybe we could add a DWARF verifier check that a
DW_TAG_subprogram at least has a DW_AT_name attribute.

Update #1:

Reland with a fix to create a declaration DIE when the declaration is
missing from the CU's retainedTypes list. The declaration is left out
of the retainedTypes list in two cases:

1) Re-compiling pre-r266445 bitcode (in which declarations weren't added
to the retainedTypes list), and
2) Doing LTO function importing (which doesn't update the retainedTypes
list).

It's possible to handle (1) and (2) by modifying the retainedTypes list
(in AutoUpgrade, or in the LTO importing logic resp.), but I don't see
an advantage to doing it this way, as it would cause more DWARF to be
emitted compared to creating the declaration DIEs lazily.

Update #2:

Fold in a fix for call site tag emission in the split-dwarf + LTO case.

Tested with a stage2 ThinLTO+RelWithDebInfo build of clang, and with a
ReleaseLTO-g build of the test suite.

rdar://46577651, rdar://57855316, rdar://57840415, rdar://58888440

Differential Revision: https://reviews.llvm.org/D70350

show more ...

[DWARF] Emit DW_AT_call_return_pc as an address

This reverts D53469, which changed llvm's DWARF emission to emit
DW_AT_call_return_pc as a function-local offset. Such an encoding is not
compatible w

[DWARF] Emit DW_AT_call_return_pc as an address

This reverts D53469, which changed llvm's DWARF emission to emit
DW_AT_call_return_pc as a function-local offset. Such an encoding is not
compatible with post-link block re-ordering tools and isn't standards-
compliant.

In addition to reverting back to the original DW_AT_call_return_pc
encoding, teach lldb how to fix up DW_AT_call_return_pc when the address
comes from an object file pointed-to by a debug map. While doing this I
noticed that lldb's support for tail calls that cross a DSO/object file
boundary wasn't covered, so I added tests for that. This latter case
exercises the newly added return PC fixup.

The dsymutil changes in this patch were originally included in D49887:
the associated test should be sufficient to test DW_AT_call_return_pc
encoding purely on the llvm side.

Differential Revision: https://reviews.llvm.org/D72489

show more ...

[DWARF5][Debuginfo] Compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_compile_unit) do not match.

That patch fixes incompatible compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_

[DWARF5][Debuginfo] Compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_compile_unit) do not match.

That patch fixes incompatible compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_compile_unit) error.

cat split-dwarf.cpp
int main()
{
int a = 1;
return 0;
}

clang++ -O -g -gsplit-dwarf -gdwarf-5 split-dwarf.cpp; llvm-dwarfdump --verify ./a.out | grep skeleton
error: Compilation unit type (DW_UT_skeleton) and root DIE (DW_TAG_compile_unit) do not match.

The fix is to change DW_TAG_compile_unit into DW_TAG_skeleton_unit when skeleton file is generated.

Differential Revision: https://reviews.llvm.org/D70880

show more ...

[DWARF] Rename getDwarf5OrGNUCallSite{Attr,Tag}, NFC

llvm-svn: 369967

[DWARF] Pick the DWARF5 OP_entry_value opcode on Darwin

Use the GNU extension for OP_entry_value consistently (i.e. whenever GNU
extensions are used for TAG_call_site).

llvm-svn: 369966

Reland "[DwarfDebug] Dump call site debug info"

The build failure found after the rL365467 has been
resolved.

Differential Revision: https://reviews.llvm.org/D60716

llvm-svn: 367446

Revert "[DwarfDebug] Dump call site debug info"

A build failure was found on the SystemZ platform.

This reverts commit 9e7e73578e54cd22b3c7af4b54274d743b6607cc.

llvm-svn: 365886

[DwarfDebug] Dump call site debug info

Dump the DWARF information about call sites and call site parameters into
debug info sections.

The patch also provides an interface for the interpretation of

[DwarfDebug] Dump call site debug info

Dump the DWARF information about call sites and call site parameters into
debug info sections.

The patch also provides an interface for the interpretation of instructions
that could load values of a call site parameters in order to generate DWARF
about the call site parameters.

([13/13] Introduce the debug entry values.)

Co-authored-by: Ananth Sowda <[email protected]>
Co-authored-by: Nikola Prica <[email protected]>
Co-authored-by: Ivan Baev <[email protected]>

Differential Revision: https://reviews.llvm.org/D60716

llvm-svn: 365467

show more ...

DebugInfo: Emit only declarations (not whole definitions) of non-unit user defined types into type units

While this doesn't come up in reasonable cases currently (the only user
defined types not in

DebugInfo: Emit only declarations (not whole definitions) of non-unit user defined types into type units

While this doesn't come up in reasonable cases currently (the only user
defined types not in type units are ones without linkage - which makes
for near-ODR violations, because it'd be a type with linkage referencing
a type without linkage - such a type can't be validly defined in more
than one TU, so arguably it shouldn't be in a type unit to begin with -
but it's a convenient way to demonstrate an issue that will become more
revalent with homed modular debug info type definitions - which also
don't need to be in type units but more legitimately so).

Precursor to the Clang change to de-type-unit (by omitting the
'identifier') types homed due to strong linkage vtables. (making that
change without this one would lead to major type duplication in type
units)

llvm-svn: 359122

show more ...

Add LLVM IR debug info support for Fortran COMMON blocks

COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly langua

Add LLVM IR debug info support for Fortran COMMON blocks

COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly language programming. A COMMON block is a named area of memory that holds a collection of variables. Fortran subprograms may map the COMMON block memory area to their own, possibly distinct, non-empty list of variables. A Fortran COMMON block might look like the following example.

COMMON /ALPHA/ I, J

For this construct, the compiler generates a new scope-like DI construct (!DICommonBlock) into which variables (see I, J above) can be placed. As the common block implies a range of storage with global lifetime, the !DICommonBlock refers to a !DIGlobalVariable. The Fortran variable that comprise the COMMON block are also linked via metadata to offsets within the global variable that stands for the entire common block.

@alpha_ = common global %alphabytes_ zeroinitializer, align 64, !dbg !27, !dbg !30, !dbg !33
!14 = distinct !DISubprogram(…)
!20 = distinct !DICommonBlock(scope: !14, declaration: !25, name: "alpha")
!25 = distinct !DIGlobalVariable(scope: !20, name: "common alpha", type: !24)
!27 = !DIGlobalVariableExpression(var: !25, expr: !DIExpression())
!29 = distinct !DIGlobalVariable(scope: !20, name: "i", file: !3, type: !28)
!30 = !DIGlobalVariableExpression(var: !29, expr: !DIExpression())
!31 = distinct !DIGlobalVariable(scope: !20, name: "j", file: !3, type: !28)
!32 = !DIExpression(DW_OP_plus_uconst, 4)
!33 = !DIGlobalVariableExpression(var: !31, expr: !32)

The DWARF generated for this is as follows.

DW_TAG_common_block:
DW_AT_name: alpha
DW_AT_location: @alpha_+0
DW_TAG_variable:
DW_AT_name: common alpha
DW_AT_type: array of 8 bytes
DW_AT_location: @alpha_+0
DW_TAG_variable:
DW_AT_name: i
DW_AT_type: integer*4
DW_AT_location: @Alpha+0
DW_TAG_variable:
DW_AT_name: j
DW_AT_type: integer*4
DW_AT_location: @Alpha+4

Patch by Eric Schweitz!

Differential Revision: https://reviews.llvm.org/D54327

llvm-svn: 357934

show more ...