[all-commits] [llvm/llvm-project] 79daaf: Reland: [DWARF] Allow cross-CU references of subpr...
Vedant Kumar via All-commits
all-commits at lists.llvm.org
Fri Dec 20 15:26:54 PST 2019
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: 79daafc90308787b52a5d3a7586e82acd5e374b3
https://github.com/llvm/llvm-project/commit/79daafc90308787b52a5d3a7586e82acd5e374b3
Author: Vedant Kumar <vsk at apple.com>
Date: 2019-12-20 (Fri, 20 Dec 2019)
Changed paths:
M llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
M llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
M llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h
M llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
A llvm/test/DebugInfo/AArch64/unretained-declaration-subprogram.ll
A llvm/test/DebugInfo/X86/lto-cross-cu-call-origin-ref.ll
Log Message:
-----------
Reland: [DWARF] Allow cross-CU references of subprogram definitions
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:
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.
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
Differential Revision: https://reviews.llvm.org/D70350
Commit: fa4701e1979553c2df61698ac1ac212627630442
https://github.com/llvm/llvm-project/commit/fa4701e1979553c2df61698ac1ac212627630442
Author: Vedant Kumar <vsk at apple.com>
Date: 2019-12-20 (Fri, 20 Dec 2019)
Changed paths:
M llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
M llvm/test/DebugInfo/MIR/AArch64/dbgcall-site-orr-moves.mir
M llvm/test/DebugInfo/MIR/X86/debug-call-site-param.mir
M llvm/test/DebugInfo/X86/lto-cross-cu-call-origin-ref.ll
Log Message:
-----------
[DWARF] Defer creating declaration DIEs until we prepare call site info
It isn't necessary to create DIEs for all of the declaration subprograms
in a CU's retainedTypes list. We can defer creating these subprograms
until we need to prepare a call site tag that refers to one.
This cleanup was mentioned in passing in D70350.
Compare: https://github.com/llvm/llvm-project/compare/f72d001e0998...fa4701e19795
More information about the All-commits
mailing list