maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/DebugInfo/X86/parameters.ll

119 lines
7.4 KiB
LLVM
Raw Normal View History

DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
; REQUIRES: object-emission
;
Give this X86-specific test a triple so it's actually X86-specific. llvm-svn: 184443
2013-06-21 01:31:32 +08:00
; RUN: llc -mtriple=x86_64-unknown-linux-gnu -O0 -filetype=obj < %s > %t
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
; RUN: llvm-dwarfdump %t | FileCheck %s
; Test case derived from compiling the following source with clang -g:
;
; namespace pr14763 {
; struct foo {
; foo(const foo&);
; };
;
; foo func(foo f) {
; return f; // reference 'f' for now because otherwise we hit another bug
; }
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
;
; void sink(void*);
;
; void func2(bool b, foo g) {
; if (b)
; sink(&g); // reference 'f' for now because otherwise we hit another bug
; }
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
; }
; CHECK: debug_info contents
Reapply an improved version of r180816/180817. Change the informal convention of DBG_VALUE machine instructions so that we can express a register-indirect address with an offset of 0. The old convention was that a DBG_VALUE is a register-indirect value if the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE is register-indirect if the first operand is a register and the second operand is an immediate. For plain register values the combination reg, reg is used. MachineInstrBuilder::BuildMI knows how to build the new DBG_VALUES. rdar://problem/13658587 llvm-svn: 185966
2013-07-10 04:28:37 +08:00
; 0x74 is DW_OP_breg4, showing that the parameter is accessed indirectly
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
; (with a zero offset) from the register parameter
Reapply an improved version of r180816/180817. Change the informal convention of DBG_VALUE machine instructions so that we can express a register-indirect address with an offset of 0. The old convention was that a DBG_VALUE is a register-indirect value if the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE is register-indirect if the first operand is a register and the second operand is an immediate. For plain register values the combination reg, reg is used. MachineInstrBuilder::BuildMI knows how to build the new DBG_VALUES. rdar://problem/13658587 llvm-svn: 185966
2013-07-10 04:28:37 +08:00
; CHECK: DW_AT_location{{.*}}(<0x0{{.}}> 74 00
DebugInfo: Following up to r209677, refactor local variable emission to delay the choice between emitting the definition attributes or using DW_AT_abstract_definition This doesn't fix the abstract variable handling yet, but it introduces a similar delay mechanism as was added for subprograms, causing DW_AT_location to be reordered to the beginning of the attribute list for local variables, and fixes all the test fallout for that. A subsequent commit will remove the abstract variable handling in DbgVariable and just do the abstract variable lookup at module end to ensure that abstract variables introduced after their concrete counterparts are appropriately referenced by the concrete variable. llvm-svn: 210943
2014-06-14 06:18:23 +08:00
; CHECK-NOT: DW_TAG
; CHECK: DW_AT_name{{.*}} = "f"
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
; CHECK: DW_AT_location{{.*}}([[G_LOC:0x[0-9]*]])
DebugInfo: Following up to r209677, refactor local variable emission to delay the choice between emitting the definition attributes or using DW_AT_abstract_definition This doesn't fix the abstract variable handling yet, but it introduces a similar delay mechanism as was added for subprograms, causing DW_AT_location to be reordered to the beginning of the attribute list for local variables, and fixes all the test fallout for that. A subsequent commit will remove the abstract variable handling in DbgVariable and just do the abstract variable lookup at module end to ensure that abstract variables introduced after their concrete counterparts are appropriately referenced by the concrete variable. llvm-svn: 210943
2014-06-14 06:18:23 +08:00
; CHECK-NOT: DW_TAG
; CHECK: DW_AT_name{{.*}} = "g"
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
; CHECK: debug_loc contents
; CHECK-NEXT: [[G_LOC]]: Beginning
; CHECK-NEXT: Ending
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
; CHECK-NEXT: Location description: 74 00
%"struct.pr14763::foo" = type { i8 }
; Function Attrs: uwtable
define void @_ZN7pr147634funcENS_3fooE(%"struct.pr14763::foo"* noalias sret %agg.result, %"struct.pr14763::foo"* %f) #0 {
entry:
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
call void @llvm.dbg.declare(metadata !{%"struct.pr14763::foo"* %f}, metadata !22, metadata !{i32 786690}), !dbg !24
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
call void @_ZN7pr147633fooC1ERKS0_(%"struct.pr14763::foo"* %agg.result, %"struct.pr14763::foo"* %f), !dbg !25
ret void, !dbg !25
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
}
; Function Attrs: nounwind readnone
Move the complex address expression out of DIVariable and into an extra argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! Note: I accidentally committed a bogus older version of this patch previously. llvm-svn: 218787
2014-10-02 02:55:02 +08:00
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
declare void @_ZN7pr147633fooC1ERKS0_(%"struct.pr14763::foo"*, %"struct.pr14763::foo"*) #2
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
; Function Attrs: uwtable
define void @_ZN7pr147635func2EbNS_3fooE(i1 zeroext %b, %"struct.pr14763::foo"* %g) #0 {
entry:
%b.addr = alloca i8, align 1
%frombool = zext i1 %b to i8
store i8 %frombool, i8* %b.addr, align 1
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
call void @llvm.dbg.declare(metadata !{i8* %b.addr}, metadata !26, metadata !{i32 786690}), !dbg !27
call void @llvm.dbg.declare(metadata !{%"struct.pr14763::foo"* %g}, metadata !28, metadata !{i32 786690}), !dbg !27
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
%0 = load i8* %b.addr, align 1, !dbg !29
%tobool = trunc i8 %0 to i1, !dbg !29
br i1 %tobool, label %if.then, label %if.end, !dbg !29
if.then: ; preds = %entry
%1 = bitcast %"struct.pr14763::foo"* %g to i8*, !dbg !31
call void @_ZN7pr147634sinkEPv(i8* %1), !dbg !31
br label %if.end, !dbg !31
if.end: ; preds = %if.then, %entry
ret void, !dbg !32
}
declare void @_ZN7pr147634sinkEPv(i8*) #2
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
attributes #0 = { uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { nounwind readnone }
attributes #2 = { "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" }
!llvm.dbg.cu = !{!0}
Debug Info: update testing cases to specify the debug info version number. We are going to drop debug info without a version number or with a different version number, to make sure we don't crash when we see bitcode files with different debug info metadata format. llvm-svn: 195504
2013-11-23 05:49:45 +08:00
!llvm.module.flags = !{!21, !33}
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!0 = metadata !{i32 786449, metadata !1, i32 4, metadata !"clang version 3.4 ", i1 false, metadata !"", i32 0, metadata !2, metadata !2, metadata !3, metadata !2, metadata !2, metadata !"", i32 1} ; [ DW_TAG_compile_unit ] [/tmp/pass.cpp] [DW_LANG_C_plus_plus]
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
!1 = metadata !{metadata !"pass.cpp", metadata !"/tmp"}
DebugInfo: Remove some unneeded conditionals now that DIBuilder no longer emits zero-length arrays as {i32 0} A bunch of test cases needed to be cleaned up for this, many my fault - when implementid imported modules I updated test cases by simply duplicating the prior metadata field - which wasn't always the empty metadata entry. llvm-svn: 200731
2014-02-04 09:23:52 +08:00
!2 = metadata !{}
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
!3 = metadata !{metadata !4, metadata !17}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!4 = metadata !{i32 786478, metadata !1, metadata !5, metadata !"func", metadata !"func", metadata !"_ZN7pr147634funcENS_3fooE", i32 6, metadata !6, i1 false, i1 true, i32 0, i32 0, null, i32 256, i1 false, void (%"struct.pr14763::foo"*, %"struct.pr14763::foo"*)* @_ZN7pr147634funcENS_3fooE, null, null, metadata !2, i32 6} ; [ DW_TAG_subprogram ] [line 6] [def] [func]
!5 = metadata !{i32 786489, metadata !1, null, metadata !"pr14763", i32 1} ; [ DW_TAG_namespace ] [pr14763] [line 1]
!6 = metadata !{i32 786453, i32 0, null, metadata !"", i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !7, i32 0, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
!7 = metadata !{metadata !8, metadata !8}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!8 = metadata !{i32 786451, metadata !1, metadata !5, metadata !"foo", i32 2, i64 8, i64 8, i32 0, i32 0, null, metadata !9, i32 0, null, null, null} ; [ DW_TAG_structure_type ] [foo] [line 2, size 8, align 8, offset 0] [def] [from ]
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
!9 = metadata !{metadata !10}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!10 = metadata !{i32 786478, metadata !1, metadata !8, metadata !"foo", metadata !"foo", metadata !"", i32 3, metadata !11, i1 false, i1 false, i32 0, i32 0, null, i32 256, i1 false, null, null, i32 0, metadata !16, i32 3} ; [ DW_TAG_subprogram ] [line 3] [foo]
!11 = metadata !{i32 786453, i32 0, null, metadata !"", i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !12, i32 0, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
!12 = metadata !{null, metadata !13, metadata !14}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!13 = metadata !{i32 786447, i32 0, null, metadata !"", i32 0, i64 64, i64 64, i64 0, i32 1088, metadata !8} ; [ DW_TAG_pointer_type ] [line 0, size 64, align 64, offset 0] [artificial] [from foo]
!14 = metadata !{i32 786448, null, null, null, i32 0, i64 0, i64 0, i64 0, i32 0, metadata !15} ; [ DW_TAG_reference_type ] [line 0, size 0, align 0, offset 0] [from ]
!15 = metadata !{i32 786470, null, null, metadata !"", i32 0, i64 0, i64 0, i64 0, i32 0, metadata !8} ; [ DW_TAG_const_type ] [line 0, size 0, align 0, offset 0] [from foo]
DebugInfo: PR14763/r183329 correct the location of indirect parameters We had been papering over a problem with location info for non-trivial types passed by value by emitting their type as references (this caused the debugger to interpret the location information correctly, but broke the type of the function). r183329 corrected the type information but lead to the debugger interpreting the pointer parameter as the value - the debug info describing the location needed an extra dereference. Use a new flag in DIVariable to add the extra indirection (either by promoting an existing DW_OP_reg (parameter passed in a register) to DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n (parameter passed on the stack). llvm-svn: 184368
2013-06-20 05:55:13 +08:00
!16 = metadata !{i32 786468}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!17 = metadata !{i32 786478, metadata !1, metadata !5, metadata !"func2", metadata !"func2", metadata !"_ZN7pr147635func2EbNS_3fooE", i32 12, metadata !18, i1 false, i1 true, i32 0, i32 0, null, i32 256, i1 false, void (i1, %"struct.pr14763::foo"*)* @_ZN7pr147635func2EbNS_3fooE, null, null, metadata !2, i32 12} ; [ DW_TAG_subprogram ] [line 12] [def] [func2]
!18 = metadata !{i32 786453, i32 0, null, metadata !"", i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !19, i32 0, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
!19 = metadata !{null, metadata !20, metadata !8}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!20 = metadata !{i32 786468, null, null, metadata !"bool", i32 0, i64 8, i64 8, i64 0, i32 0, i32 2} ; [ DW_TAG_base_type ] [bool] [line 0, size 8, align 8, offset 0, enc DW_ATE_boolean]
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
!21 = metadata !{i32 2, metadata !"Dwarf Version", i32 3}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!22 = metadata !{i32 786689, metadata !4, metadata !"f", metadata !23, i32 16777222, metadata !8, i32 8192, i32 0} ; [ DW_TAG_arg_variable ] [f] [line 6]
!23 = metadata !{i32 786473, metadata !1} ; [ DW_TAG_file_type ] [/tmp/pass.cpp]
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
!24 = metadata !{i32 6, i32 0, metadata !4, null}
!25 = metadata !{i32 7, i32 0, metadata !4, null}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!26 = metadata !{i32 786689, metadata !17, metadata !"b", metadata !23, i32 16777228, metadata !20, i32 0, i32 0} ; [ DW_TAG_arg_variable ] [b] [line 12]
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
!27 = metadata !{i32 12, i32 0, metadata !17, null}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!28 = metadata !{i32 786689, metadata !17, metadata !"g", metadata !23, i32 33554444, metadata !8, i32 8192, i32 0} ; [ DW_TAG_arg_variable ] [g] [line 12]
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
!29 = metadata !{i32 13, i32 0, metadata !30, null}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!30 = metadata !{i32 786443, metadata !1, metadata !17, i32 13, i32 0, i32 0} ; [ DW_TAG_lexical_block ] [/tmp/pass.cpp]
DebugInfo: don't use location lists when the location covers the whole function anyway Fix up three tests - one that was relying on abbreviation number, another relying on a location list in this case (& testing raw asm, changed that to use dwarfdump on the debug_info now that that's where the location is), and another which was added in r184368 - exposing a bug in that fix that is exposed when we emit the location inline rather than through a location list. Fix that bug while I'm here. llvm-svn: 184387
2013-06-20 08:25:24 +08:00
!31 = metadata !{i32 14, i32 0, metadata !30, null}
!32 = metadata !{i32 15, i32 0, metadata !17, null}
Revert "DI: Fold constant arguments into a single MDString" This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
2014-10-03 06:15:31 +08:00
!33 = metadata !{i32 1, metadata !"Debug Info Version", i32 1}