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/inlined-arguments.ll

80 lines
4.6 KiB
LLVM
Raw Normal View History

Add 'REQUIRES: object-emission' to DebugInfo/inlined-arguments.ll. llvm-svn: 185465
2013-07-03 03:21:43 +08:00
; REQUIRES: object-emission
Reland r200340 - 'Add line table debug info to COFF files when using a win32 triple' This incorporates a couple of fixes reviewed at http://llvm-reviews.chandlerc.com/D2651 llvm-svn: 200440
2014-01-30 09:39:17 +08:00
; RUN: %llc_dwarf -filetype=obj < %s > %t
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
; RUN: llvm-dwarfdump %t | FileCheck %s
; IR generated from clang -O -g with the following source
;
; void f1(int x, int y);
; void f3(int line);
; void f2() {
; f1(1, 2);
; }
; void f1(int x, int y) {
; f3(y);
; }
; CHECK: DW_AT_name{{.*}}"f1"
; CHECK: DW_TAG_formal_parameter
DebugInfo: Refactor some tests to allow DW_AT_name to not be the first attribute in a local variable. In an effort to fix concrete variables referencing abstract origins where the concrete variable preceeds the first inlined usage, the addition of attributes such as name, file, etc will be delayed until the end of the module (to wait to see if any inlined instances have occurred, thus necessitating an abstract definition that the concrete definition should also reference). These test cases don't actually need to care about this ordering of attributes, so update them to be more resilient to such changes coming in the near future. llvm-svn: 210940
2014-06-14 05:52:33 +08:00
; CHECK-NOT: DW_TAG
; CHECK: DW_AT_name{{.*}}"x"
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
; CHECK: DW_TAG_formal_parameter
DebugInfo: Refactor some tests to allow DW_AT_name to not be the first attribute in a local variable. In an effort to fix concrete variables referencing abstract origins where the concrete variable preceeds the first inlined usage, the addition of attributes such as name, file, etc will be delayed until the end of the module (to wait to see if any inlined instances have occurred, thus necessitating an abstract definition that the concrete definition should also reference). These test cases don't actually need to care about this ordering of attributes, so update them to be more resilient to such changes coming in the near future. llvm-svn: 210940
2014-06-14 05:52:33 +08:00
; CHECK-NOT: DW_TAG
; CHECK: DW_AT_name{{.*}}"y"
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
; Function Attrs: uwtable
define void @_Z2f2v() #0 {
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
tail call void @llvm.dbg.value(metadata !15, i64 0, metadata !16, metadata !{i32 786690}), !dbg !18
tail call void @llvm.dbg.value(metadata !19, i64 0, metadata !20, metadata !{i32 786690}), !dbg !18
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
tail call void @_Z2f3i(i32 2), !dbg !21
ret void, !dbg !22
}
; Function Attrs: uwtable
define void @_Z2f1ii(i32 %x, i32 %y) #0 {
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
tail call void @llvm.dbg.value(metadata !{i32 %x}, i64 0, metadata !13, metadata !{i32 786690}), !dbg !23
tail call void @llvm.dbg.value(metadata !{i32 %y}, i64 0, metadata !14, metadata !{i32 786690}), !dbg !23
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
tail call void @_Z2f3i(i32 %y), !dbg !24
ret void, !dbg !25
}
declare void @_Z2f3i(i32) #1
; 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.value(metadata, i64, metadata, metadata) #2
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
Update to remove the no-frame-pointer-elim-non-leaf flag if it was set to 'false'. llvm-svn: 189068
2013-08-23 05:28:54 +08:00
attributes #0 = { uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" }
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
attributes #2 = { nounwind readnone }
!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 = !{!26}
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +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 true, metadata !"", i32 0, metadata !2, metadata !2, metadata !3, metadata !2, metadata !2, metadata !"", i32 1} ; [ DW_TAG_compile_unit ] [/usr/local/google/home/blaikie/dev/scratch/exp.cpp] [DW_LANG_C_plus_plus]
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
!1 = metadata !{metadata !"exp.cpp", metadata !"/usr/local/google/home/blaikie/dev/scratch"}
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 !{}
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
!3 = metadata !{metadata !4, 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
!4 = metadata !{i32 786478, metadata !1, metadata !5, metadata !"f2", metadata !"f2", metadata !"_Z2f2v", i32 3, metadata !6, i1 false, i1 true, i32 0, i32 0, null, i32 256, i1 true, void ()* @_Z2f2v, null, null, metadata !2, i32 3} ; [ DW_TAG_subprogram ] [line 3] [def] [f2]
!5 = metadata !{i32 786473, metadata !1} ; [ DW_TAG_file_type ] [/usr/local/google/home/blaikie/dev/scratch/exp.cpp]
!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 ]
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
!7 = metadata !{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
!8 = metadata !{i32 786478, metadata !1, metadata !5, metadata !"f1", metadata !"f1", metadata !"_Z2f1ii", i32 6, metadata !9, i1 false, i1 true, i32 0, i32 0, null, i32 256, i1 true, void (i32, i32)* @_Z2f1ii, null, null, metadata !12, i32 6} ; [ DW_TAG_subprogram ] [line 6] [def] [f1]
!9 = metadata !{i32 786453, i32 0, null, metadata !"", i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !10, i32 0, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
!10 = metadata !{null, metadata !11, metadata !11}
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
!11 = metadata !{i32 786468, null, null, metadata !"int", i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] [int] [line 0, size 32, align 32, offset 0, enc DW_ATE_signed]
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
!12 = metadata !{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 786689, metadata !8, metadata !"x", metadata !5, i32 16777222, metadata !11, i32 0, i32 0} ; [ DW_TAG_arg_variable ] [x] [line 6]
!14 = metadata !{i32 786689, metadata !8, metadata !"y", metadata !5, i32 33554438, metadata !11, i32 0, i32 0} ; [ DW_TAG_arg_variable ] [y] [line 6]
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
!15 = metadata !{i32 undef}
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
!16 = metadata !{i32 786689, metadata !8, metadata !"x", metadata !5, i32 16777222, metadata !11, i32 0, metadata !17} ; [ DW_TAG_arg_variable ] [x] [line 6]
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
!17 = metadata !{i32 4, i32 0, metadata !4, null}
!18 = metadata !{i32 6, i32 0, metadata !8, metadata !17}
!19 = metadata !{i32 2}
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 786689, metadata !8, metadata !"y", metadata !5, i32 33554438, metadata !11, i32 0, metadata !17} ; [ DW_TAG_arg_variable ] [y] [line 6]
PR15662: Optimized debug info produces out of order function parameters When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters. If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source. This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source. llvm-svn: 183297
2013-06-05 13:39:59 +08:00
!21 = metadata !{i32 7, i32 0, metadata !8, metadata !17}
!22 = metadata !{i32 5, i32 0, metadata !4, null}
!23 = metadata !{i32 6, i32 0, metadata !8, null}
!24 = metadata !{i32 7, i32 0, metadata !8, 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
!25 = metadata !{i32 8, i32 0, metadata !8, null} ; [ DW_TAG_imported_declaration ]
!26 = metadata !{i32 1, metadata !"Debug Info Version", i32 1}