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/spill-nospill.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

114 lines
5.1 KiB
LLVM
Raw Normal View History

Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs" After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
2017-09-21 02:19:08 +08:00
; RUN: llc < %s | FileCheck %s
; RUN: llc < %s -filetype=obj | llvm-dwarfdump - | FileCheck %s --check-prefix=DWARF
; This test creates two UserValues in LiveDebugVariables with one location
; each. x must be spilled, but y will be allocated to a CSR. x's location
; should be indirect, but y's should be direct.
; C source:
; #define FORCE_SPILL() \
; __asm volatile("" : : : \
; "rax", "rbx", "rcx", "rdx", "rsi", "rdi", "rbp", "r8", \
; "r9", "r10", "r11", "r12", "r13", "r14", "r15")
; int g(int);
; int f() {
; int x = g(0);
; FORCE_SPILL();
; int y = g(0);
; g(y);
; g(y);
; g(y);
; return x + y;
; }
; CHECK-LABEL: f: # @f
; CHECK: callq g
; CHECK: movl %eax, [[X_OFFS:[0-9]+]](%rsp) # 4-byte Spill
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; CHECK: #DEBUG_VALUE: f:x <- [DW_OP_plus_uconst [[X_OFFS]]] [$rsp+0]
Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs" After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
2017-09-21 02:19:08 +08:00
; CHECK: #APP
; CHECK: #NO_APP
; CHECK: callq g
; CHECK: movl %eax, %[[CSR:[^ ]*]]
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; CHECK: #DEBUG_VALUE: f:y <- $esi
Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding" Re-enable commit r323991 now that r325931 has been committed to make MachineOperand::isRenamable() check more conservative w.r.t. code changes and opt-in on a per-target basis. llvm-svn: 326208
2018-02-28 00:59:10 +08:00
; CHECK: movl %eax, %ecx
Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs" After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
2017-09-21 02:19:08 +08:00
; CHECK: callq g
; CHECK: movl %[[CSR]], %ecx
; CHECK: callq g
; CHECK: movl %[[CSR]], %ecx
; CHECK: callq g
; CHECK: movl [[X_OFFS]](%rsp), %eax # 4-byte Reload
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; CHECK: #DEBUG_VALUE: f:x <- $eax
Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs" After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
2017-09-21 02:19:08 +08:00
; CHECK: addl %[[CSR]], %eax
; DWARF: DW_TAG_variable
; DWARF-NEXT: DW_AT_location (
[DebugInfo] Unify dumping of address ranges Summary: This patch unifies the printing of address ranges as [0x0, 0x1). rdar://34822059 Reviewers: aprantl, dblaikie Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D42056 llvm-svn: 322543
2018-01-16 19:17:57 +08:00
; DWARF-NEXT: [{{.*}}, {{.*}}): DW_OP_breg7 RSP+36
; DWARF-NEXT: [{{.*}}, {{.*}}): DW_OP_reg0 RAX)
Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs" After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
2017-09-21 02:19:08 +08:00
; DWARF-NEXT: DW_AT_name ("x")
; DWARF: DW_TAG_variable
; DWARF-NEXT: DW_AT_location (
[DebugInfo] Unify dumping of address ranges Summary: This patch unifies the printing of address ranges as [0x0, 0x1). rdar://34822059 Reviewers: aprantl, dblaikie Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D42056 llvm-svn: 322543
2018-01-16 19:17:57 +08:00
; DWARF-NEXT: [{{.*}}, {{.*}}): DW_OP_reg4 RSI)
Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs" After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
2017-09-21 02:19:08 +08:00
; DWARF-NEXT: DW_AT_name ("y")
; ModuleID = 'spill-nospill.c'
source_filename = "spill-nospill.c"
target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc19.0.24215"
; Function Attrs: nounwind uwtable
define i32 @f() local_unnamed_addr #0 !dbg !8 {
entry:
%call = tail call i32 @g(i32 0) #3, !dbg !15
tail call void @llvm.dbg.value(metadata i32 %call, metadata !13, metadata !DIExpression()), !dbg !16
tail call void asm sideeffect "", "~{rax},~{rbx},~{rcx},~{rdx},~{rsi},~{rdi},~{rbp},~{r8},~{r9},~{r10},~{r11},~{r12},~{r13},~{r14},~{r15},~{dirflag},~{fpsr},~{flags}"() #3, !dbg !17, !srcloc !18
%call1 = tail call i32 @g(i32 0) #3, !dbg !19
tail call void @llvm.dbg.value(metadata i32 %call1, metadata !14, metadata !DIExpression()), !dbg !20
%call2 = tail call i32 @g(i32 %call1) #3, !dbg !21
%call3 = tail call i32 @g(i32 %call1) #3, !dbg !22
%call4 = tail call i32 @g(i32 %call1) #3, !dbg !23
%add = add nsw i32 %call1, %call, !dbg !24
ret i32 %add, !dbg !25
}
declare i32 @g(i32) local_unnamed_addr #1
; Function Attrs: nounwind readnone speculatable
declare void @llvm.dbg.value(metadata, metadata, metadata) #2
Migrate function attribute "no-frame-pointer-elim"="false" to "frame-pointer"="none" as cleanups after D56351
2019-12-25 08:11:33 +08:00
attributes #0 = { nounwind uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "frame-pointer"="none" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "frame-pointer"="none" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }
Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs" After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
2017-09-21 02:19:08 +08:00
attributes #2 = { nounwind readnone speculatable }
attributes #3 = { nounwind }
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!3, !4, !5, !6}
!llvm.ident = !{!7}
!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 6.0.0 ", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)
!1 = !DIFile(filename: "spill-nospill.c", directory: "C:\5Csrc\5Cllvm-project\5Cbuild")
!2 = !{}
!3 = !{i32 2, !"Dwarf Version", i32 4}
!4 = !{i32 2, !"Debug Info Version", i32 3}
!5 = !{i32 1, !"wchar_size", i32 2}
!6 = !{i32 7, !"PIC Level", i32 2}
!7 = !{!"clang version 6.0.0 "}
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label. In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
2018-05-09 10:40:45 +08:00
!8 = distinct !DISubprogram(name: "f", scope: !1, file: !1, line: 8, type: !9, isLocal: false, isDefinition: true, scopeLine: 8, isOptimized: true, unit: !0, retainedNodes: !12)
Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs" After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
2017-09-21 02:19:08 +08:00
!9 = !DISubroutineType(types: !10)
!10 = !{!11}
!11 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!12 = !{!13, !14}
!13 = !DILocalVariable(name: "x", scope: !8, file: !1, line: 9, type: !11)
!14 = !DILocalVariable(name: "y", scope: !8, file: !1, line: 11, type: !11)
!15 = !DILocation(line: 9, column: 11, scope: !8)
!16 = !DILocation(line: 9, column: 7, scope: !8)
!17 = !DILocation(line: 10, column: 3, scope: !8)
!18 = !{i32 -2147472112}
!19 = !DILocation(line: 11, column: 11, scope: !8)
!20 = !DILocation(line: 11, column: 7, scope: !8)
!21 = !DILocation(line: 12, column: 3, scope: !8)
!22 = !DILocation(line: 13, column: 3, scope: !8)
!23 = !DILocation(line: 14, column: 3, scope: !8)
!24 = !DILocation(line: 15, column: 12, scope: !8)
!25 = !DILocation(line: 15, column: 3, scope: !8)