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/live-debug-vars-dse.mir

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

148 lines
5.7 KiB
Plaintext
Raw Normal View History

[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
# RUN: llc -start-after=machine-scheduler %s -o - | FileCheck %s
# C source:
# void escape(int *);
# extern int global;
# void f(int x) {
# escape(&x);
# x = 1;
# global = x;
# x = 2;
# escape(&x);
# }
# CHECK-LABEL: f: # @f
# CHECK: movl %ecx, [[OFF_X:[0-9]+]](%rsp)
Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field" This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref.
2020-02-06 01:27:44 +08:00
# CHECK: #DEBUG_VALUE: f:x <- [DW_OP_plus_uconst [[OFF_X]]] [$rsp+0]
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
# CHECK: leaq [[OFF_X]](%rsp), %rsi
# CHECK: callq escape
# CHECK: #DEBUG_VALUE: f:x <- 1
# CHECK: movl $1, global(%rip)
Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field" This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref.
2020-02-06 01:27:44 +08:00
# CHECK: #DEBUG_VALUE: f:x <- [DW_OP_plus_uconst [[OFF_X]]] [$rsp+0]
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
# CHECK: movl $2, [[OFF_X]](%rsp)
# CHECK: callq escape
# CHECK: retq
--- |
; ModuleID = '<stdin>'
source_filename = "dse.c"
target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc19.0.24215"
@global = external global i32, align 4
; Function Attrs: nounwind readnone speculatable
declare void @llvm.dbg.value(metadata, metadata, metadata) #0
declare void @escape(i32*)
; Function Attrs: nounwind uwtable
define void @f(i32 %x) #1 !dbg !8 {
entry:
%x.addr = alloca i32, align 4
store i32 %x, i32* %x.addr, align 4
Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field" This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref.
2020-02-06 01:27:44 +08:00
call void @llvm.dbg.value(metadata i32* %x.addr, metadata !13, metadata !DIExpression()), !dbg !14
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
call void @escape(i32* %x.addr), !dbg !15
call void @llvm.dbg.value(metadata i32 1, metadata !13, metadata !DIExpression()), !dbg !16
store i32 1, i32* @global, align 4, !dbg !17
Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field" This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref.
2020-02-06 01:27:44 +08:00
call void @llvm.dbg.value(metadata i32* %x.addr, metadata !13, metadata !DIExpression()), !dbg !18
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
store i32 2, i32* %x.addr, align 4, !dbg !18
call void @escape(i32* %x.addr), !dbg !19
ret void, !dbg !20
}
; Function Attrs: nounwind
declare void @llvm.stackprotector(i8*, i8**) #2
attributes #0 = { nounwind readnone speculatable }
attributes #1 = { nounwind uwtable }
attributes #2 = { 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: "dse.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: 3, type: !9, isLocal: false, isDefinition: true, scopeLine: 3, flags: DIFlagPrototyped, isOptimized: true, unit: !0, retainedNodes: !12)
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
!9 = !DISubroutineType(types: !10)
!10 = !{null, !11}
!11 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!12 = !{!13}
!13 = !DILocalVariable(name: "x", arg: 1, scope: !8, file: !1, line: 3, type: !11)
!14 = !DILocation(line: 3, column: 12, scope: !8)
!15 = !DILocation(line: 4, column: 3, scope: !8)
!16 = !DILocation(line: 5, column: 5, scope: !8)
!17 = !DILocation(line: 6, column: 10, scope: !8)
!18 = !DILocation(line: 7, column: 5, scope: !8)
!19 = !DILocation(line: 8, column: 3, scope: !8)
!20 = !DILocation(line: 9, column: 1, scope: !8)
...
---
name: f
[Alignment] Use llvm::Align in MachineFunction and TargetLowering - fixes mir parsing Summary: This catches malformed mir files which specify alignment as log2 instead of pow2. See https://reviews.llvm.org/D65945 for reference, This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: MatzeB, qcolombet, dschuff, arsenm, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, s.egerton, pzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67433 llvm-svn: 371608
2019-09-11 19:16:48 +08:00
alignment: 16
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
exposesReturnsTwice: false
legalized: false
regBankSelected: false
selected: false
tracksRegLiveness: true
registers:
- { id: 0, class: gr32, preferred-register: '' }
- { id: 1, class: gr64, preferred-register: '' }
liveins:
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
- { reg: '$ecx', virtual-reg: '%0' }
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
frameInfo:
isFrameAddressTaken: false
isReturnAddressTaken: false
hasStackMap: false
hasPatchPoint: false
stackSize: 0
offsetAdjustment: 0
maxAlignment: 8
adjustsStack: false
hasCalls: true
stackProtector: ''
maxCallFrameSize: 4294967295
hasOpaqueSPAdjustment: false
hasVAStart: false
hasMustTailInVarArgFunc: false
savePoint: ''
restorePoint: ''
fixedStack:
stack:
- { id: 0, name: x.addr, type: default, offset: 0, size: 4, alignment: 4,
Describe stack-id as an enum This patch changes MIR stack-id from an integer to an enum, and adds printing/parsing support for this in MIR files. The default stack-id '0' is now renamed to 'default'. This should make MIR tests that have stack objects with different stack-ids more descriptive. It also clarifies code operating on StackID. Reviewers: arsenm, thegameg, qcolombet Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D60137 llvm-svn: 363533
2019-06-17 17:13:29 +08:00
stack-id: default, callee-saved-register: '', debug-info-variable: '',
[MIR] Add support for debug metadata for fixed stack objects Debug var, expr and loc were only supported for non-fixed stack objects. This patch adds the following fields to the "fixedStack:" entries, and renames the ones from "stack:" to: * debug-info-variable * debug-info-expression * debug-info-location Differential Revision: https://reviews.llvm.org/D46032 llvm-svn: 330859
2018-04-26 02:58:06 +08:00
debug-info-expression: '', debug-info-location: '' }
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
constants:
body: |
bb.0.entry:
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
liveins: $ecx
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
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
%0 = COPY $ecx
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
MOV32mr %stack.0.x.addr, 1, _, 0, _, %0 :: (store 4 into %ir.x.addr)
Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field" This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref.
2020-02-06 01:27:44 +08:00
DBG_VALUE %stack.0.x.addr, 0, !13, !DIExpression(), debug-location !14
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
ADJCALLSTACKDOWN64 32, 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp, debug-location !15
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
%1 = LEA64r %stack.0.x.addr, 1, _, 0, _
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
$rcx = COPY %1, debug-location !15
CALL64pcrel32 @escape, csr_win64, implicit $rsp, implicit $ssp, implicit $rcx, implicit-def $rsp, implicit-def $ssp, debug-location !15
ADJCALLSTACKUP64 32, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp, debug-location !15
MachineOperand/MIParser: Do not print debug-use flag, infer it The debug-use flag must be set exactly for uses on DBG_VALUEs. This is so obvious that it can be trivially inferred while parsing. This will reduce noise when printing while omitting an information that has little value to the user. The parser will keep recognizing the flag for compatibility with old `.mir` files. Differential Revision: https://reviews.llvm.org/D53903 llvm-svn: 345671
2018-10-31 07:28:27 +08:00
DBG_VALUE 1, _, !13, !DIExpression(), debug-location !16
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
MOV32mi $rip, 1, _, @global, _, 1, debug-location !17 :: (store 4 into @global)
Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field" This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref.
2020-02-06 01:27:44 +08:00
DBG_VALUE %stack.0.x.addr, 0, !13, !DIExpression(), debug-location !18
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
MOV32mi %stack.0.x.addr, 1, _, 0, _, 2, debug-location !18 :: (store 4 into %ir.x.addr)
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
ADJCALLSTACKDOWN64 32, 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp, debug-location !19
$rcx = COPY %1, debug-location !19
CALL64pcrel32 @escape, csr_win64, implicit $rsp, implicit $ssp, implicit $rcx, implicit-def $rsp, implicit-def $ssp, debug-location !19
ADJCALLSTACKUP64 32, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp, debug-location !19
[DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect values Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
2017-10-04 01:59:02 +08:00
RET 0, debug-location !20
...