RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-24 19:52:54 +01:00
Code Issues Projects Releases Wiki Activity
4f4ea10917
llvm-mirror/test/Linker/subprogram-linkonce-weak.ll

165 lines
6.9 KiB
LLVM
Raw Normal View History

Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; RUN: llvm-link %s %S/Inputs/subprogram-linkonce-weak.ll -S -o %t1
; RUN: FileCheck %s -check-prefix=LW -check-prefix=CHECK <%t1
; RUN: llvm-link %S/Inputs/subprogram-linkonce-weak.ll %s -S -o %t2
; RUN: FileCheck %s -check-prefix=WL -check-prefix=CHECK <%t2
Make the default triple optional by allowing an empty string When building LLVM as a (potentially dynamic) library that can be linked against by multiple compilers, the default triple is not really meaningful. We allow to explicitely set it to an empty string when configuring LLVM. In this case, said "target independent" tests in the test suite that are using the default triple are disabled by matching the newly available feature "default_triple". Reviewers: probinson, echristo Differential Revision: http://reviews.llvm.org/D12660 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 247775
2015-09-16 07:34:32 +02:00
; REQUIRES: default_triple
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; This testcase tests the following flow:
; - File A defines a linkonce version of @foo which has inlined into @bar.
; - File B defines a weak version of @foo (different definition).
; - Linkage rules state File B version of @foo wins.
; - @bar still has inlined debug info related to the linkonce @foo.
;
; This should fix PR22792, although the testcase was hand-written. There's a
; RUN line with a crasher for llc at the end with checks for the DWARF output.
; The LW prefix means linkonce (this file) first, then weak (the other file).
; The WL prefix means weak (the other file) first, then linkonce (this file).
; We'll see @bar before @foo if this file is first.
DI: Reverse direction of subprogram -> function edge. Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
2015-11-05 23:03:56 +01:00
; LW: define i32 @bar({{.*}} !dbg ![[BARSP:[0-9]+]]
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; LW: %sum = add i32 %a, %b, !dbg ![[FOOINBAR:[0-9]+]]
; LW: ret i32 %sum, !dbg ![[BARRET:[0-9]+]]
DI: Reverse direction of subprogram -> function edge. Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
2015-11-05 23:03:56 +01:00
; LW: define weak i32 @foo({{.*}} !dbg ![[WEAKFOOSP:[0-9]+]]
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; LW: %sum = call i32 @fastadd(i32 %a, i32 %b), !dbg ![[FOOCALL:[0-9]+]]
; LW: ret i32 %sum, !dbg ![[FOORET:[0-9]+]]
; We'll see @foo before @bar if this file is second.
DI: Reverse direction of subprogram -> function edge. Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
2015-11-05 23:03:56 +01:00
; WL: define weak i32 @foo({{.*}} !dbg ![[WEAKFOOSP:[0-9]+]]
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; WL: %sum = call i32 @fastadd(i32 %a, i32 %b), !dbg ![[FOOCALL:[0-9]+]]
; WL: ret i32 %sum, !dbg ![[FOORET:[0-9]+]]
DI: Reverse direction of subprogram -> function edge. Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
2015-11-05 23:03:56 +01:00
; WL: define i32 @bar({{.*}} !dbg ![[BARSP:[0-9]+]]
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; WL: %sum = add i32 %a, %b, !dbg ![[FOOINBAR:[0-9]+]]
; WL: ret i32 %sum, !dbg ![[BARRET:[0-9]+]]
DI: Reverse direction of subprogram -> function edge. Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
2015-11-05 23:03:56 +01:00
define i32 @bar(i32 %a, i32 %b) !dbg !3 {
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
entry:
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
%sum = add i32 %a, %b, !dbg !DILocation(line: 2, scope: !4,
inlinedAt: !DILocation(line: 12, scope: !3))
ret i32 %sum, !dbg !DILocation(line: 13, scope: !3)
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
}
DI: Reverse direction of subprogram -> function edge. Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
2015-11-05 23:03:56 +01:00
define linkonce i32 @foo(i32 %a, i32 %b) !dbg !4 {
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
entry:
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
%sum = add i32 %a, %b, !dbg !DILocation(line: 2, scope: !4)
ret i32 %sum, !dbg !DILocation(line: 3, scope: !4)
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
}
!llvm.module.flags = !{!0}
!0 = !{i32 2, !"Debug Info Version", i32 3}
; CHECK-LABEL: !llvm.dbg.cu =
; LW-SAME: !{![[LCU:[0-9]+]], ![[WCU:[0-9]+]]}
; WL-SAME: !{![[WCU:[0-9]+]], ![[LCU:[0-9]+]]}
!llvm.dbg.cu = !{!1}
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
; LW: ![[LCU]] = distinct !DICompileUnit(
; LW: ![[WCU]] = distinct !DICompileUnit(
; LW: ![[BARSP]] = distinct !DISubprogram(name: "bar",{{.*}} unit: ![[LCU]]
; LW: ![[FOOINBAR]] = !DILocation(line: 2, scope: ![[FOOSP:.*]], inlinedAt: ![[BARIA:[0-9]+]])
; LW: ![[FOOSP]] = distinct !DISubprogram(name: "foo",{{.*}} unit: ![[LCU]]
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
; LW: ![[BARIA]] = !DILocation(line: 12, scope: ![[BARSP]])
; LW: ![[BARRET]] = !DILocation(line: 13, scope: ![[BARSP]])
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
; LW: ![[WEAKFOOSP]] = distinct !DISubprogram(name: "foo",{{.*}} unit: ![[WCU]]
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
; LW: ![[FOOCALL]] = !DILocation(line: 52, scope: ![[WEAKFOOSP]])
; LW: ![[FOORET]] = !DILocation(line: 53, scope: ![[WEAKFOOSP]])
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; Same as above, but reordered.
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
; WL: ![[WCU]] = distinct !DICompileUnit(
; WL: ![[LCU]] = distinct !DICompileUnit(
; WL: ![[WEAKFOOSP]] = distinct !DISubprogram(name: "foo",{{.*}} unit: ![[WCU]]
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
; WL: ![[FOOCALL]] = !DILocation(line: 52, scope: ![[WEAKFOOSP]])
; WL: ![[FOORET]] = !DILocation(line: 53, scope: ![[WEAKFOOSP]])
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
; WL: ![[BARSP]] = distinct !DISubprogram(name: "bar",{{.*}} unit: ![[LCU]]
; WL: ![[FOOINBAR]] = !DILocation(line: 2, scope: ![[FOOSP:.*]], inlinedAt: ![[BARIA:[0-9]+]])
; WL: ![[FOOSP]] = distinct !DISubprogram(name: "foo",{{.*}} unit: ![[LCU]]
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
; WL: ![[BARIA]] = !DILocation(line: 12, scope: ![[BARSP]])
; WL: ![[BARRET]] = !DILocation(line: 13, scope: ![[BARSP]])
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
!1 = distinct !DICompileUnit(language: DW_LANG_C99, file: !2, emissionKind: FullDebug)
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
!2 = !DIFile(filename: "bar.c", directory: "/path/to/dir")
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
!3 = distinct !DISubprogram(file: !2, scope: !2, line: 11, name: "bar", type: !5, unit: !1)
!4 = distinct !DISubprogram(file: !2, scope: !2, line: 1, name: "foo", type: !5, unit: !1)
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
!5 = !DISubroutineType(types: !{})
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; Crasher for llc.
; REQUIRES: object-emission
; RUN: %llc_dwarf -filetype=obj -O0 %t1 -o %t1.o
llvm-dwarfdump: Replace -debug-dump=sect option with individual options. As discussed on llvm-dev in http://lists.llvm.org/pipermail/llvm-dev/2017-September/117301.html this changes the command line interface of llvm-dwarfdump to match the one used by the dwarfdump utility shipping on macOS. In addition to being shorter to type this format also has the advantage of allowing more than one section to be specified at the same time. In a nutshell, with this change $ llvm-dwarfdump --debug-dump=info $ llvm-dwarfdump --debug-dump=apple-objc becomes $ dwarfdump --debug-info --apple-objc Differential Revision: https://reviews.llvm.org/D37714 llvm-svn: 312970
2017-09-12 00:59:45 +02:00
; RUN: llvm-dwarfdump %t1.o --all | FileCheck %s -check-prefix=DWLW -check-prefix=DW
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; RUN: %llc_dwarf -filetype=obj -O0 %t2 -o %t2.o
llvm-dwarfdump: Replace -debug-dump=sect option with individual options. As discussed on llvm-dev in http://lists.llvm.org/pipermail/llvm-dev/2017-September/117301.html this changes the command line interface of llvm-dwarfdump to match the one used by the dwarfdump utility shipping on macOS. In addition to being shorter to type this format also has the advantage of allowing more than one section to be specified at the same time. In a nutshell, with this change $ llvm-dwarfdump --debug-dump=info $ llvm-dwarfdump --debug-dump=apple-objc becomes $ dwarfdump --debug-info --apple-objc Differential Revision: https://reviews.llvm.org/D37714 llvm-svn: 312970
2017-09-12 00:59:45 +02:00
; RUN: llvm-dwarfdump %t2.o --all | FileCheck %s -check-prefix=DWWL -check-prefix=DW
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; Check that the debug info for the discarded linkonce version of @foo doesn't
; reference any code, and that the other subprograms look correct.
; DW-LABEL: .debug_info contents:
; DWLW: DW_TAG_compile_unit
; DWLW: DW_AT_name {{.*}}"bar.c"
; DWLW: DW_TAG_subprogram
; DWLW-NOT: DW_AT_low_pc
; DWLW-NOT: DW_AT_high_pc
; DWLW: DW_AT_name {{.*}}foo
Fix subprogram-linkonce-weak.ll and subprogram-linkonce-weak-odr.ll for Windows. llvm-svn: 233375
2015-03-27 14:52:12 +01:00
; DWLW: DW_AT_decl_file {{.*}}"/path/to/dir{{/|\\}}bar.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWLW: DW_AT_decl_line {{.*}}(1)
; DWLW: DW_TAG_subprogram
; DWLW: DW_AT_low_pc
; DWLW: DW_AT_high_pc
; DWLW: DW_AT_name {{.*}}bar
Fix subprogram-linkonce-weak.ll and subprogram-linkonce-weak-odr.ll for Windows. llvm-svn: 233375
2015-03-27 14:52:12 +01:00
; DWLW: DW_AT_decl_file {{.*}}"/path/to/dir{{/|\\}}bar.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWLW: DW_AT_decl_line {{.*}}(11)
; DWLW: DW_TAG_inlined_subroutine
; DWLW: DW_AT_abstract_origin
; DWLW: DW_TAG_compile_unit
; DWLW: DW_AT_name {{.*}}"foo.c"
; DWLW: DW_TAG_subprogram
; DWLW: DW_AT_low_pc
; DWLW: DW_AT_high_pc
; DWLW: DW_AT_name {{.*}}foo
Fix subprogram-linkonce-weak.ll and subprogram-linkonce-weak-odr.ll for Windows. llvm-svn: 233375
2015-03-27 14:52:12 +01:00
; DWLW: DW_AT_decl_file {{.*}}"/path/to/dir{{/|\\}}foo.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWLW: DW_AT_decl_line {{.*}}(51)
; The DWARF output is already symmetric (just reordered).
; DWWL: DW_TAG_compile_unit
; DWWL: DW_AT_name {{.*}}"foo.c"
; DWWL: DW_TAG_subprogram
; DWWL: DW_AT_low_pc
; DWWL: DW_AT_high_pc
; DWWL: DW_AT_name {{.*}}foo
Fix subprogram-linkonce-weak.ll and subprogram-linkonce-weak-odr.ll for Windows. llvm-svn: 233375
2015-03-27 14:52:12 +01:00
; DWWL: DW_AT_decl_file {{.*}}"/path/to/dir{{/|\\}}foo.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWWL: DW_AT_decl_line {{.*}}(51)
; DWWL: DW_TAG_compile_unit
; DWWL: DW_AT_name {{.*}}"bar.c"
; DWWL: DW_TAG_subprogram
; DWWL-NOT: DW_AT_low_pc
; DWWL-NOT: DW_AT_high_pc
; DWWL: DW_AT_name {{.*}}foo
Fix subprogram-linkonce-weak.ll and subprogram-linkonce-weak-odr.ll for Windows. llvm-svn: 233375
2015-03-27 14:52:12 +01:00
; DWWL: DW_AT_decl_file {{.*}}"/path/to/dir{{/|\\}}bar.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWWL: DW_AT_decl_line {{.*}}(1)
; DWWL: DW_TAG_subprogram
; DWWL: DW_AT_low_pc
; DWWL: DW_AT_high_pc
; DWWL: DW_AT_name {{.*}}bar
Fix subprogram-linkonce-weak.ll and subprogram-linkonce-weak-odr.ll for Windows. llvm-svn: 233375
2015-03-27 14:52:12 +01:00
; DWWL: DW_AT_decl_file {{.*}}"/path/to/dir{{/|\\}}bar.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWWL: DW_AT_decl_line {{.*}}(11)
; DWWL: DW_TAG_inlined_subroutine
; DWWL: DW_AT_abstract_origin
; DW-LABEL: .debug_line contents:
; Check that we have the right things in the line table as well.
[DebugInfo] Support DWARF v5 source code embedding extension In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. In this extension a content type is added, DW_LNCT_LLVM_source, which contains the embedded source code of the file. Add new optional attribute for !DIFile IR metadata called source which contains source text. Use this to output the source to the DWARF line table of code objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM to support optional source. Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output format of llvm-dwarfdump to make room for the new attribute on file_names entries, and support embedded sources for the -source option in llvm-objdump. Differential Revision: https://reviews.llvm.org/D42765 llvm-svn: 325970
2018-02-24 00:01:06 +01:00
; DWLW-LABEL: file_names[ 1]:
; DWLW-NEXT: name: "bar.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWLW: 2 0 1 0 0 is_stmt prologue_end
[DebugInfo] Support DWARF v5 source code embedding extension In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. In this extension a content type is added, DW_LNCT_LLVM_source, which contains the embedded source code of the file. Add new optional attribute for !DIFile IR metadata called source which contains source text. Use this to output the source to the DWARF line table of code objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM to support optional source. Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output format of llvm-dwarfdump to make room for the new attribute on file_names entries, and support embedded sources for the -source option in llvm-objdump. Differential Revision: https://reviews.llvm.org/D42765 llvm-svn: 325970
2018-02-24 00:01:06 +01:00
; DWLW-LABEL: file_names[ 1]:
; DWLW-NEXT: name: "foo.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWLW: 52 0 1 0 0 is_stmt prologue_end
; DWLW-NOT: prologue_end
[DebugInfo] Support DWARF v5 source code embedding extension In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. In this extension a content type is added, DW_LNCT_LLVM_source, which contains the embedded source code of the file. Add new optional attribute for !DIFile IR metadata called source which contains source text. Use this to output the source to the DWARF line table of code objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM to support optional source. Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output format of llvm-dwarfdump to make room for the new attribute on file_names entries, and support embedded sources for the -source option in llvm-objdump. Differential Revision: https://reviews.llvm.org/D42765 llvm-svn: 325970
2018-02-24 00:01:06 +01:00
; DWWL-LABEL: file_names[ 1]:
; DWWL-NEXT: name: "foo.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWWL: 52 0 1 0 0 is_stmt prologue_end
[DebugInfo] Support DWARF v5 source code embedding extension In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. In this extension a content type is added, DW_LNCT_LLVM_source, which contains the embedded source code of the file. Add new optional attribute for !DIFile IR metadata called source which contains source text. Use this to output the source to the DWARF line table of code objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM to support optional source. Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output format of llvm-dwarfdump to make room for the new attribute on file_names entries, and support embedded sources for the -source option in llvm-objdump. Differential Revision: https://reviews.llvm.org/D42765 llvm-svn: 325970
2018-02-24 00:01:06 +01:00
; DWWL-LABEL: file_names[ 1]:
; DWWL-NEXT: name: "bar.c"
Reapply "Linker: Drop function pointers for overridden subprograms" This reverts commit r233254, effectively reapplying r233164 (and its successors), with an additional testcase for when subprograms match exactly. This fixes PR22792 (again). I'm using the same approach, but I've moved up the call to `stripReplacedSubprograms()`. The function pointers need to be dropped before mapping any metadata from the source module, or else this can drop the function from new subprograms that have merged (via Metadata uniquing) with the old ones. Dropping the pointers first prevents them from merging. **** The original commit message follows. **** Linker: Drop function pointers for overridden subprograms Instead of dropping subprograms that have been overridden, just set their function pointers to `nullptr`. This is a minor adjustment to the stop-gap fix for PR21910 committed in r224487, and fixes the crasher from PR22792. The problem that r224487 put a band-aid on: how do we find the canonical subprogram for a `Function`? Since the backend currently relies on `DebugInfoFinder` (which does a naive in-order traversal of compile units and picks the first subprogram) for this, r224487 tried dropping non-canonical subprograms. Dropping subprograms fails because the backend *also* builds up a map from subprogram to compile unit (`DwarfDebug::SPMap`) based on the subprogram lists. A missing subprogram causes segfaults later when an inlined reference (such as in this testcase) is created. Instead, just drop the `Function` pointer to `nullptr`, which nicely mirrors what happens when an already-inlined `Function` is optimized out. We can't really be sure that it's the same definition anyway, as the testcase demonstrates. This still isn't completely satisfactory. Two flaws at least that I can think of: - I still haven't found a straightforward way to make this symmetric in the IR. (Interestingly, the DWARF output is already symmetric, and I've tested for that to be sure we don't regress.) - Using `DebugInfoFinder` to find the canonical subprogram for a function is kind of crazy. We should just attach metadata to the function, like this: define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) { llvm-svn: 233302
2015-03-26 19:35:30 +01:00
; DWWL: 2 0 1 0 0 is_stmt prologue_end
; DWWL-NOT: prologue_end
Reference in New Issue Copy Permalink