llvm-project/llvm/lib/CodeGen/AsmPrinter/DbgEntityHistoryCalculator.cpp

396 lines
15 KiB
C++
Raw Normal View History

//===- llvm/CodeGen/AsmPrinter/DbgEntityHistoryCalculator.cpp -------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "llvm/CodeGen/DbgEntityHistoryCalculator.h"
#include "llvm/ADT/BitVector.h"
#include "llvm/ADT/STLExtras.h"
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
#include "llvm/ADT/SmallSet.h"
#include "llvm/ADT/SmallVector.h"
#include "llvm/CodeGen/MachineBasicBlock.h"
#include "llvm/CodeGen/MachineFunction.h"
#include "llvm/CodeGen/MachineInstr.h"
#include "llvm/CodeGen/MachineOperand.h"
#include "llvm/CodeGen/TargetLowering.h"
#include "llvm/CodeGen/TargetRegisterInfo.h"
#include "llvm/CodeGen/TargetSubtargetInfo.h"
#include "llvm/IR/DebugInfoMetadata.h"
#include "llvm/IR/DebugLoc.h"
#include "llvm/MC/MCRegisterInfo.h"
#include "llvm/Support/Debug.h"
#include "llvm/Support/raw_ostream.h"
#include <cassert>
#include <map>
#include <utility>
using namespace llvm;
#define DEBUG_TYPE "dwarfdebug"
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
namespace {
using EntryIndex = DbgValueHistoryMap::EntryIndex;
}
// If @MI is a DBG_VALUE with debug value described by a
// defined register, returns the number of this register.
// In the other case, returns 0.
static unsigned isDescribedByReg(const MachineInstr &MI) {
assert(MI.isDebugValue());
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
assert(MI.getNumOperands() == 4);
// If location of variable is described using a register (directly or
// indirectly), this register is always a first operand.
return MI.getOperand(0).isReg() ? MI.getOperand(0).getReg() : 0;
}
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
bool DbgValueHistoryMap::startDbgValue(InlinedEntity Var,
const MachineInstr &MI,
EntryIndex &NewIndex) {
// Instruction range should start with a DBG_VALUE instruction for the
// variable.
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
assert(MI.isDebugValue() && "not a DBG_VALUE");
auto &Entries = VarEntries[Var];
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
if (!Entries.empty() && Entries.back().isDbgValue() &&
!Entries.back().isClosed() &&
Entries.back().getInstr()->isIdenticalTo(MI)) {
LLVM_DEBUG(dbgs() << "Coalescing identical DBG_VALUE entries:\n"
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
<< "\t" << Entries.back().getInstr() << "\t" << MI
<< "\n");
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
return false;
}
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
Entries.emplace_back(&MI, Entry::DbgValue);
NewIndex = Entries.size() - 1;
return true;
}
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
EntryIndex DbgValueHistoryMap::startClobber(InlinedEntity Var,
const MachineInstr &MI) {
auto &Entries = VarEntries[Var];
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
Entries.emplace_back(&MI, Entry::Clobber);
return Entries.size() - 1;
}
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
void DbgValueHistoryMap::Entry::endEntry(EntryIndex Index) {
// For now, instruction ranges are not allowed to cross basic block
// boundaries.
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
assert(isDbgValue() && "Setting end index for non-debug value");
assert(!isClosed() && "End index has already been set");
EndIndex = Index;
}
unsigned DbgValueHistoryMap::getRegisterForVar(InlinedEntity Var) const {
const auto &I = VarEntries.find(Var);
if (I == VarEntries.end())
return 0;
const auto &Entries = I->second;
if (Entries.empty() || Entries.back().isClosed())
return 0;
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
if (Entries.back().isClobber())
return 0;
return isDescribedByReg(*Entries.back().getInstr());
}
void DbgLabelInstrMap::addInstr(InlinedEntity Label, const MachineInstr &MI) {
assert(MI.isDebugLabel() && "not a DBG_LABEL");
LabelInstr[Label] = &MI;
}
namespace {
// Maps physreg numbers to the variables they describe.
using InlinedEntity = DbgValueHistoryMap::InlinedEntity;
using RegDescribedVarsMap = std::map<unsigned, SmallVector<InlinedEntity, 1>>;
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
// Keeps track of the debug value entries that are currently live for each
// inlined entity. As the history map entries are stored in a SmallVector, they
// may be moved at insertion of new entries, so store indices rather than
// pointers.
using DbgValueEntriesMap = std::map<InlinedEntity, SmallSet<EntryIndex, 1>>;
} // end anonymous namespace
// Claim that @Var is not described by @RegNo anymore.
static void dropRegDescribedVar(RegDescribedVarsMap &RegVars, unsigned RegNo,
InlinedEntity Var) {
const auto &I = RegVars.find(RegNo);
assert(RegNo != 0U && I != RegVars.end());
auto &VarSet = I->second;
const auto &VarPos = llvm::find(VarSet, Var);
assert(VarPos != VarSet.end());
VarSet.erase(VarPos);
// Don't keep empty sets in a map to keep it as small as possible.
if (VarSet.empty())
RegVars.erase(I);
}
// Claim that @Var is now described by @RegNo.
static void addRegDescribedVar(RegDescribedVarsMap &RegVars, unsigned RegNo,
InlinedEntity Var) {
assert(RegNo != 0U);
auto &VarSet = RegVars[RegNo];
assert(!is_contained(VarSet, Var));
VarSet.push_back(Var);
}
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
static void clobberRegEntries(InlinedEntity Var, unsigned RegNo,
const MachineInstr &ClobberingInstr,
DbgValueEntriesMap &LiveEntries,
DbgValueHistoryMap &HistMap) {
EntryIndex ClobberIndex = HistMap.startClobber(Var, ClobberingInstr);
// TODO: Close all preceding live entries that are clobbered by this
// instruction.
EntryIndex ValueIndex = ClobberIndex - 1;
auto &ValueEntry = HistMap.getEntry(Var, ValueIndex);
ValueEntry.endEntry(ClobberIndex);
LiveEntries[Var].erase(ValueIndex);
}
/// Add a new debug value for \p Var. Closes all overlapping debug values.
static void handleNewDebugValue(InlinedEntity Var, const MachineInstr &DV,
RegDescribedVarsMap &RegVars,
DbgValueEntriesMap &LiveEntries,
DbgValueHistoryMap &HistMap) {
// TODO: We should track all registers which this variable is currently
// described by.
if (unsigned PrevReg = HistMap.getRegisterForVar(Var))
dropRegDescribedVar(RegVars, PrevReg, Var);
EntryIndex NewIndex;
if (HistMap.startDbgValue(Var, DV, NewIndex)) {
// If we have created a new debug value entry, close all preceding
// live entries that overlap.
SmallVector<EntryIndex, 4> IndicesToErase;
const DIExpression *DIExpr = DV.getDebugExpression();
for (auto Index : LiveEntries[Var]) {
auto &Entry = HistMap.getEntry(Var, Index);
assert(Entry.isDbgValue() && "Not a DBG_VALUE in LiveEntries");
const MachineInstr &DV = *Entry.getInstr();
if (DIExpr->fragmentsOverlap(DV.getDebugExpression())) {
IndicesToErase.push_back(Index);
Entry.endEntry(NewIndex);
}
}
// Drop all entries that have ended, and mark the new entry as live.
for (auto Index : IndicesToErase)
LiveEntries[Var].erase(Index);
LiveEntries[Var].insert(NewIndex);
}
if (unsigned NewReg = isDescribedByReg(DV))
addRegDescribedVar(RegVars, NewReg, Var);
}
// Terminate the location range for variables described by register at
// @I by inserting @ClobberingInstr to their history.
static void clobberRegisterUses(RegDescribedVarsMap &RegVars,
RegDescribedVarsMap::iterator I,
DbgValueHistoryMap &HistMap,
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
DbgValueEntriesMap &LiveEntries,
const MachineInstr &ClobberingInstr) {
// Iterate over all variables described by this register and add this
// instruction to their history, clobbering it.
for (const auto &Var : I->second)
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
clobberRegEntries(Var, I->first, ClobberingInstr, LiveEntries, HistMap);
RegVars.erase(I);
}
// Terminate the location range for variables described by register
// @RegNo by inserting @ClobberingInstr to their history.
static void clobberRegisterUses(RegDescribedVarsMap &RegVars, unsigned RegNo,
DbgValueHistoryMap &HistMap,
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
DbgValueEntriesMap &LiveEntries,
const MachineInstr &ClobberingInstr) {
const auto &I = RegVars.find(RegNo);
if (I == RegVars.end())
return;
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
clobberRegisterUses(RegVars, I, HistMap, LiveEntries, ClobberingInstr);
}
// Returns the first instruction in @MBB which corresponds to
// the function epilogue, or nullptr if @MBB doesn't contain an epilogue.
static const MachineInstr *getFirstEpilogueInst(const MachineBasicBlock &MBB) {
auto LastMI = MBB.getLastNonDebugInstr();
if (LastMI == MBB.end() || !LastMI->isReturn())
return nullptr;
// Assume that epilogue starts with instruction having the same debug location
// as the return instruction.
DebugLoc LastLoc = LastMI->getDebugLoc();
auto Res = LastMI;
CodeGen: Give MachineBasicBlock::reverse_iterator a handle to the current MI Now that MachineBasicBlock::reverse_instr_iterator knows when it's at the end (since r281168 and r281170), implement MachineBasicBlock::reverse_iterator directly on top of an ilist::reverse_iterator by adding an IsReverse template parameter to MachineInstrBundleIterator. This replaces another hard-to-reason-about use of std::reverse_iterator on list iterators, matching the changes for ilist::reverse_iterator from r280032 (see the "out of scope" section at the end of that commit message). MachineBasicBlock::reverse_iterator now has a handle to the current node and has obvious invalidation semantics. r280032 has a more detailed explanation of how list-style reverse iterators (invalidated when the pointed-at node is deleted) are different from vector-style reverse iterators like std::reverse_iterator (invalidated on every operation). A great motivating example is this commit's changes to lib/CodeGen/DeadMachineInstructionElim.cpp. Note: If your out-of-tree backend deletes instructions while iterating on a MachineBasicBlock::reverse_iterator or converts between MachineBasicBlock::iterator and MachineBasicBlock::reverse_iterator, you'll need to update your code in similar ways to r280032. The following table might help: [Old] ==> [New] delete &*RI, RE = end() delete &*RI++ RI->erase(), RE = end() RI++->erase() reverse_iterator(I) std::prev(I).getReverse() reverse_iterator(I) ++I.getReverse() --reverse_iterator(I) I.getReverse() reverse_iterator(std::next(I)) I.getReverse() RI.base() std::prev(RI).getReverse() RI.base() ++RI.getReverse() --RI.base() RI.getReverse() std::next(RI).base() RI.getReverse() (For more details, have a look at r280032.) llvm-svn: 281172
2016-09-12 02:51:28 +08:00
for (MachineBasicBlock::const_reverse_iterator I = LastMI.getReverse(),
E = MBB.rend();
I != E; ++I) {
if (I->getDebugLoc() != LastLoc)
return &*Res;
Res = &*I;
}
// If all instructions have the same debug location, assume whole MBB is
// an epilogue.
return &*MBB.begin();
}
// Collect registers that are modified in the function body (their
// contents is changed outside of the prologue and epilogue).
static void collectChangingRegs(const MachineFunction *MF,
const TargetRegisterInfo *TRI,
BitVector &Regs) {
for (const auto &MBB : *MF) {
auto FirstEpilogueInst = getFirstEpilogueInst(MBB);
for (const auto &MI : MBB) {
// Avoid looking at prologue or epilogue instructions.
if (&MI == FirstEpilogueInst)
break;
if (MI.getFlag(MachineInstr::FrameSetup))
continue;
// Look for register defs and register masks. Register masks are
// typically on calls and they clobber everything not in the mask.
for (const MachineOperand &MO : MI.operands()) {
// Skip virtual registers since they are handled by the parent.
if (MO.isReg() && MO.isDef() && MO.getReg() &&
!TRI->isVirtualRegister(MO.getReg())) {
for (MCRegAliasIterator AI(MO.getReg(), TRI, true); AI.isValid();
++AI)
Regs.set(*AI);
} else if (MO.isRegMask()) {
Regs.setBitsNotInMask(MO.getRegMask());
}
}
}
}
}
void llvm::calculateDbgEntityHistory(const MachineFunction *MF,
const TargetRegisterInfo *TRI,
DbgValueHistoryMap &DbgValues,
DbgLabelInstrMap &DbgLabels) {
BitVector ChangingRegs(TRI->getNumRegs());
collectChangingRegs(MF, TRI, ChangingRegs);
const TargetLowering *TLI = MF->getSubtarget().getTargetLowering();
unsigned SP = TLI->getStackPointerRegisterToSaveRestore();
RegDescribedVarsMap RegVars;
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
DbgValueEntriesMap LiveEntries;
for (const auto &MBB : *MF) {
for (const auto &MI : MBB) {
if (!MI.isDebugInstr()) {
// Not a DBG_VALUE instruction. It may clobber registers which describe
// some variables.
for (const MachineOperand &MO : MI.operands()) {
if (MO.isReg() && MO.isDef() && MO.getReg()) {
// Ignore call instructions that claim to clobber SP. The AArch64
// backend does this for aggregate function arguments.
if (MI.isCall() && MO.getReg() == SP)
continue;
// If this is a virtual register, only clobber it since it doesn't
// have aliases.
if (TRI->isVirtualRegister(MO.getReg()))
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
clobberRegisterUses(RegVars, MO.getReg(), DbgValues, LiveEntries,
MI);
// If this is a register def operand, it may end a debug value
// range.
else {
for (MCRegAliasIterator AI(MO.getReg(), TRI, true); AI.isValid();
++AI)
if (ChangingRegs.test(*AI))
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
clobberRegisterUses(RegVars, *AI, DbgValues, LiveEntries, MI);
}
} else if (MO.isRegMask()) {
// If this is a register mask operand, clobber all debug values in
// non-CSRs.
for (unsigned I : ChangingRegs.set_bits()) {
// Don't consider SP to be clobbered by register masks.
if (unsigned(I) != SP && TRI->isPhysicalRegister(I) &&
MO.clobbersPhysReg(I)) {
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
clobberRegisterUses(RegVars, I, DbgValues, LiveEntries, MI);
}
}
}
}
continue;
}
if (MI.isDebugValue()) {
assert(MI.getNumOperands() > 1 && "Invalid DBG_VALUE instruction!");
// Use the base variable (without any DW_OP_piece expressions)
// as index into History. The full variables including the
// piece expressions are attached to the MI.
const DILocalVariable *RawVar = MI.getDebugVariable();
assert(RawVar->isValidLocationForIntrinsic(MI.getDebugLoc()) &&
"Expected inlined-at fields to agree");
InlinedEntity Var(RawVar, MI.getDebugLoc()->getInlinedAt());
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
handleNewDebugValue(Var, MI, RegVars, LiveEntries, DbgValues);
} else if (MI.isDebugLabel()) {
assert(MI.getNumOperands() == 1 && "Invalid DBG_LABEL instruction!");
const DILabel *RawLabel = MI.getDebugLabel();
assert(RawLabel->isValidLocationForIntrinsic(MI.getDebugLoc()) &&
"Expected inlined-at fields to agree");
// When collecting debug information for labels, there is no MCSymbol
// generated for it. So, we keep MachineInstr in DbgLabels in order
// to query MCSymbol afterward.
InlinedEntity L(RawLabel, MI.getDebugLoc()->getInlinedAt());
DbgLabels.addInstr(L, MI);
}
}
// Make sure locations for register-described variables are valid only
// until the end of the basic block (unless it's the last basic block, in
// which case let their liveness run off to the end of the function).
if (!MBB.empty() && &MBB != &MF->back()) {
for (auto I = RegVars.begin(), E = RegVars.end(); I != E;) {
auto CurElem = I++; // CurElem can be erased below.
if (TRI->isVirtualRegister(CurElem->first) ||
ChangingRegs.test(CurElem->first))
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
clobberRegisterUses(RegVars, CurElem, DbgValues, LiveEntries,
MBB.back());
}
}
}
}
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void DbgValueHistoryMap::dump() const {
dbgs() << "DbgValueHistoryMap:\n";
for (const auto &VarRangePair : *this) {
const InlinedEntity &Var = VarRangePair.first;
const Entries &Entries = VarRangePair.second;
const DILocalVariable *LocalVar = cast<DILocalVariable>(Var.first);
const DILocation *Location = Var.second;
dbgs() << " - " << LocalVar->getName() << " at ";
if (Location)
dbgs() << Location->getFilename() << ":" << Location->getLine() << ":"
<< Location->getColumn();
else
dbgs() << "<unknown location>";
dbgs() << " --\n";
[DebugInfo] Improve handling of clobbered fragments Summary: Currently the DbgValueHistorymap only keeps track of clobbered registers for the last debug value that it has encountered. This could lead to preceding register-described debug values living on longer in the location lists than they should. See PR40283 for an example. This patch does not introduce tracking of multiple registers, but changes the DbgValueHistoryMap structure to allow for that in a follow-up patch. This patch is not NFC, as it at least fixes two bugs in DwarfDebug (both are covered in the new clobbered-fragments.mir test): * If a debug value was clobbered (its End pointer set), the value would still be added to OpenRanges, meaning that the succeeding location list entries could potentially contain stale values. * If a debug value was clobbered, and there were non-overlapping fragments that were still live after the clobbering, DwarfDebug would not create a location list entry starting directly after the clobbering instruction. This meant that the location list could have a gap until the next debug value for the variable was encountered. Before this patch, the history map was represented by <Begin, End> pairs, where a new pair was created for each new debug value. When dealing with partially overlapping register-described debug values, such as in the following example: DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32) [...] DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32) [...] $reg2 = insn1 [...] $reg3 = insn2 the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`. This would leave it up to the users of the map to be aware of the relative order of the instructions, which e.g. could make DwarfDebug::buildLocationList() needlessly complex. Instead, this patch makes the history map structure monotonically increasing by dropping the End pointer, and replacing that with explicit clobbering entries in the vector. Each debug value has an "end index", which if set, points to the entry in the vector that ends the debug value. The ending entry can either be an overlapping debug value, or an instruction which clobbers the register that the debug value is described by. The ending entry's instruction can thus either be excluded or included in the debug value's range. If the end index is not set, the debug value that the entry introduces is valid until the end of the function. Changes to test cases: * DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which describes that the fragment (0, 64) is located in RDI, was incorrectly ended by the clobbering of RAX, which the second (non-overlapping) DBG_VALUE was described by. With this patch we get a second entry that only describes RDI after that clobbering. * DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug in LiveDebugValues that is caused by it not being aware of fragments. I have added some comments in the test case about that. Also, before this patch DwarfDebug would incorrectly include a register-described debug value from a preceding block in a location list entry. Reviewers: aprantl, probinson, dblaikie, rnk, bjope Reviewed By: aprantl Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D59941 llvm-svn: 358072
2019-04-10 19:28:20 +08:00
for (const auto &E : enumerate(Entries)) {
const auto &Entry = E.value();
dbgs() << " Entry[" << E.index() << "]: ";
if (Entry.isDbgValue())
dbgs() << "Debug value\n";
else
dbgs() << "Clobber\n";
dbgs() << " Instr: " << *Entry.getInstr();
if (Entry.isDbgValue()) {
if (Entry.getEndIndex() == NoEntry)
dbgs() << " - Valid until end of function\n";
else
dbgs() << " - Closed by Entry[" << Entry.getEndIndex() << "]\n";
}
dbgs() << "\n";
}
}
}
#endif