[llvm] 206cafb - Follow up to 9fd9d56dc6b, avoid a memory leak
Jeremy Morse via llvm-commits
llvm-commits at lists.llvm.org
Wed Feb 2 08:01:22 PST 2022
Author: Jeremy Morse
Date: 2022-02-02T16:01:11Z
New Revision: 206cafb680cea0741f8c7b276351db516ff27f81
URL: https://github.com/llvm/llvm-project/commit/206cafb680cea0741f8c7b276351db516ff27f81
DIFF: https://github.com/llvm/llvm-project/commit/206cafb680cea0741f8c7b276351db516ff27f81.diff
LOG: Follow up to 9fd9d56dc6b, avoid a memory leak
Gaps in the basic block number range (from blocks being deleted or folded)
get block-value-tables allocated but never ejected, leading to a memory
leak, currently tripping up the asan buildbots. Fix this up by manually
freeing that memory.
As suggested elsewhere, if these things were owned by a unique_ptr then
cleanup would happen automagically. D118774 should eliminate the need for
this dance.
Added:
Modified:
llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
Removed:
################################################################################
diff --git a/llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp b/llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
index 55e515417ecb..3b4d717c9ab4 100644
--- a/llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
+++ b/llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
@@ -3032,6 +3032,16 @@ bool InstrRefBasedLDV::depthFirstVLocAndEmit(
if (MOutLocs[MBB->getNumber()])
EjectBlock(*MBB);
+ // Finally, there might have been gaps in the block numbering, from dead
+ // blocks being deleted or folded. In those scenarios, we might allocate a
+ // block-table that's never ejected, meaning we have to free it at the end.
+ for (unsigned int I = 0; I < MaxNumBlocks; ++I) {
+ if (MInLocs[I]) {
+ delete[] MInLocs[I];
+ delete[] MOutLocs[I];
+ }
+ }
+
return emitTransfers(AllVarsNumbering);
}
More information about the llvm-commits
mailing list