aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/LiveDebugVariables.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-09-28Remove dead code from LiveDebugVariables.cpp (NFC)Adrian Prantl1-44/+10
LiveDebugVariables doesn't propagate DBG_VALUEs accross basic block boundaries any more; this functionality was split into LiveDebugValues. We can thus drop the now dead references to LexicalScopes from LiveDebugVariables. llvm-svn: 282638
2016-09-16Place the lowered phi instruction(s) before the DEBUG_VALUE entryKeith Walker1-1/+1
When a phi node is finally lowered to a machine instruction it is important that the lowered "load" instruction is placed before the associated DEBUG_VALUE entry describing the value loaded. Renamed the existing SkipPHIsAndLabels to SkipPHIsLabelsAndDebug to more fully describe that it also skips debug entries. Then used the "new" function SkipPHIsAndLabels when the debug information should not be skipped when placing the lowered "load" instructions so that it is placed before the debug entries. Differential Revision: https://reviews.llvm.org/D23760 llvm-svn: 281727
2016-06-30CodeGen: Use MachineInstr& in LDVImpl::handleDebugValue, NFCDuncan P. N. Exon Smith1-14/+13
Avoid another implicit conversion from iterator to pointer. llvm-svn: 274294
2016-06-12Pass DebugLoc and SDLoc by const ref.Benjamin Kramer1-3/+3
This used to be free, copying and moving DebugLocs became expensive after the metadata rewrite. Passing by reference eliminates a ton of track/untrack operations. No functionality change intended. llvm-svn: 272512
2016-05-27Apply clang-tidy's misc-move-constructor-init throughout LLVM.Benjamin Kramer1-3/+4
No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270997
2016-02-27CodeGen: Take MachineInstr& in SlotIndexes and LiveIntervals, NFCDuncan P. N. Exon Smith1-4/+5
Take MachineInstr by reference instead of by pointer in SlotIndexes and the SlotIndex wrappers in LiveIntervals. The MachineInstrs here are never null, so this cleans up the API a bit. It also incidentally removes a few implicit conversions from MachineInstrBundleIterator to MachineInstr* (see PR26753). At a couple of call sites it was convenient to convert to a range-based for loop over MachineBasicBlock::instr_begin/instr_end, so I added MachineBasicBlock::instrs. llvm-svn: 262115
2016-02-18Remove uses of builtin comma operator.Richard Trieu1-6/+12
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended. llvm-svn: 261270
2016-01-29Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren1-1/+1
r259192 post commit comment. clang part in r259232, this is the LLVM part of the patch. llvm-svn: 259240
2015-12-21Fix PR24563 (LiveDebugVariables unconditionally propagates all DBG_VALUEs)Adrian Prantl1-52/+36
LiveDebugVariables unconditionally propagates all DBG_VALUE down the dominator tree, which happens to work fine if there already is another DBG_VALUE or the DBG_VALUE happends to describe a single-assignment vreg but is otherwise wrong if the DBG_VALUE is coming from only one of the predecessors. In r255759 we introduced a proper data flow analysis scheduled after LiveDebugVariables that correctly propagates DBG_VALUEs across basic block boundaries. With the new pass in place, the incorrect propagation in LiveDebugVariables can be retired witout loosing any of the benefits where LiveDebugVariables happened to do the right thing. llvm-svn: 256188
2015-11-05DI: Reverse direction of subprogram -> function edge.Peter Collingbourne1-2/+1
Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
2015-10-24Refactor: Simplify boolean conditional return statements in lib/CodeGen.Rafael Espindola1-3/+1
Patch by Richard. llvm-svn: 251213
2015-10-09CodeGen: Remove more ilist iterator implicit conversions, NFCDuncan P. N. Exon Smith1-6/+6
llvm-svn: 249879
2015-04-29IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith1-6/+6
Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-21DebugInfo: Drop rest of DIDescriptor subclassesDuncan P. N. Exon Smith1-1/+1
Delete the remaining subclasses of (the already deleted) `DIDescriptor`. Part of PR23080. llvm-svn: 235404
2015-04-16DebugInfo: Fix UserValue::match() in LiveDebugVariables after r235050Duncan P. N. Exon Smith1-5/+5
r235050 dropped the inlined-at field from `MDLocalVariable`, deferring to the `!dbg` attachments. Fix `UserValue` to take the `!dbg` into account when differentiating between variables. llvm-svn: 235140
2015-04-16DebugInfo: Gut DIScope, DIEnumerator and DISubrangeDuncan P. N. Exon Smith1-2/+2
The only class the still has API left is `DIDescriptor` itself. llvm-svn: 235067
2015-04-15DebugInfo: Remove 'inlinedAt:' field from MDLocalVariableDuncan P. N. Exon Smith1-3/+4
Remove 'inlinedAt:' from MDLocalVariable. Besides saving some memory (variables with it seem to be single largest `Metadata` contributer to memory usage right now in -g -flto builds), this stops optimization and backend passes from having to change local variables. The 'inlinedAt:' field was used by the backend in two ways: 1. To tell the backend whether and into what a variable was inlined. 2. To create a unique id for each inlined variable. Instead, rely on the 'inlinedAt:' field of the intrinsic's `!dbg` attachment, and change the DWARF backend to use a typedef called `InlinedVariable` which is `std::pair<MDLocalVariable*, MDLocation*>`. This `DebugLoc` is already passed reliably through the backend (as verified by r234021). This commit removes the check from r234021, but I added a new check (that will survive) in r235048, and changed the `DIBuilder` API in r235041 to require a `!dbg` attachment whose 'scope:` is in the same `MDSubprogram` as the variable's. If this breaks your out-of-tree testcases, perhaps the script I used (mdlocalvariable-drop-inlinedat.sh) will help; I'll attach it to PR22778 in a moment. llvm-svn: 235050
2015-04-14DebugInfo: Move DIVariable::printExtendedName() to its only callerDuncan P. N. Exon Smith1-1/+37
Move the local function `printDebugLoc()` along with it. llvm-svn: 234838
2015-04-06CodeGen: Stop using DIDescriptor::is*() and auto-castingDuncan P. N. Exon Smith1-2/+3
Same as r234255, but for lib/CodeGen and lib/Target. llvm-svn: 234258
2015-04-03CodeGen: Assert that inlined-at locations agreeDuncan P. N. Exon Smith1-13/+4
As a follow-up to r234021, assert that a debug info intrinsic variable's `MDLocalVariable::getInlinedAt()` always matches the `MDLocation::getInlinedAt()` of its `!dbg` attachment. The goal here is to get rid of `MDLocalVariable::getInlinedAt()` entirely (PR22778), but I'll let these assertions bake for a while first. If you have an out-of-tree backend that just broke, you're probably attaching the wrong `DebugLoc` to a `DBG_VALUE` instruction. The one you want is the location that was attached to the corresponding `@llvm.dbg.declare` or `@llvm.dbg.value` call that you started with. llvm-svn: 234038
2015-03-23Re-sort includes with sort-includes.py and insert raw_ostream.h where it's used.Benjamin Kramer1-0/+1
llvm-svn: 232998
2015-02-27Rewrite MachineOperand::print and MachineInstr::print to avoidEric Christopher1-5/+5
uses of TM->getSubtargetImpl and propagate to all calls. This could be a debugging regression in places where we had a TargetMachine and/or MachineFunction but don't have it as part of the MachineInstr. Fixing this would require passing a MachineFunction/Function down through the print operator, but none of the existing uses in tree seem to do this. llvm-svn: 230710
2015-01-14[cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth1-1/+0
utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
2014-10-24Added reset of LexicalScope in LiveDebugVariables reset function.Marcello Maggioni1-0/+1
llvm-svn: 220545
2014-10-01Move the complex address expression out of DIVariable and into an extraAdrian Prantl1-20/+28
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-01Revert r218778 while investigating buldbot breakage.Adrian Prantl1-28/+20
"Move the complex address expression out of DIVariable and into an extra" llvm-svn: 218782
2014-10-01Move the complex address expression out of DIVariable and into an extraAdrian Prantl1-20/+28
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! llvm-svn: 218778
2014-08-07test commit: remove trailing whitespace.Frederic Riss1-2/+2
llvm-svn: 215138
2014-08-05Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher1-3/+2
shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
2014-08-04Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher1-2/+4
information and update all callers. No functional change. llvm-svn: 214781
2014-07-25Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie1-3/+26
functions that do not have top level debug information. Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped provide a reduced reproduction, though the failure wasn't too hard to guess, and even easier with the example to confirm. The assertion that the subprogram metadata associated with an llvm::Function matches the scope data referenced by the DbgLocs on the instructions in that function is not valid under LTO. In LTO, a C++ inline function might exist in multiple CUs and the subprogram metadata nodes will refer to the same llvm::Function. In this case, depending on the order of the CUs, the first intance of the subprogram metadata may not be the one referenced by the instructions in that function and the assertion will fail. A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the assertion removed and a comment added to explain this situation. This was then reverted again in r213581 as it caused PR20367. The root cause of this was the early exit in LiveDebugVariables meant that spurious DBG_VALUE intrinsics that referenced dead variables were not removed, causing an assertion/crash later on. The fix is to have LiveDebugVariables strip all DBG_VALUE intrinsics in functions without debug info as they're not needed anyway. Test case added to cover this situation (that occurs when a debug-having function is inlined into a nodebug function) in test/DebugInfo/X86/nodebug_with_debug_loc.ll Original commit message: If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 213952
2014-07-21Revert "Recommit r212203: Don't try to construct debug LexicalScopes ↵David Blaikie1-12/+3
hierarchy for functions that do not have top level debug information." This reverts commit r212649 while I investigate/reduce/etc PR20367. llvm-svn: 213581
2014-07-09Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie1-3/+12
functions that do not have top level debug information. Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped provide a reduced reproduction, though the failure wasn't too hard to guess, and even easier with the example to confirm. The assertion that the subprogram metadata associated with an llvm::Function matches the scope data referenced by the DbgLocs on the instructions in that function is not valid under LTO. In LTO, a C++ inline function might exist in multiple CUs and the subprogram metadata nodes will refer to the same llvm::Function. In this case, depending on the order of the CUs, the first intance of the subprogram metadata may not be the one referenced by the instructions in that function and the assertion will fail. A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the assertion removed and a comment added to explain this situation. Original commit message: If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 212649
2014-07-03Temporarily revert "Don't try to construct debug LexicalScopes hierarchy for ↵Eric Christopher1-12/+3
functions that do not have top level debug information." as it appears to be breaking some LTO constructs. This reverts commit r212203. llvm-svn: 212298
2014-07-02Don't try to construct debug LexicalScopes hierarchy for functions that do ↵David Blaikie1-3/+12
not have top level debug information. If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 212203
2014-04-25This reapplies r207235 with an additional bugfixes caught by the msanAdrian Prantl1-3/+3
buildbot - do not insert debug intrinsics before phi nodes. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207269
2014-04-25Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl1-3/+3
check for" This reverts commit 207235 to investigate msan buildbot breakage. llvm-svn: 207250
2014-04-25This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl1-3/+3
AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207235
2014-04-25Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl1-3/+3
check for" Typo in testcase. llvm-svn: 207166
2014-04-25This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl1-3/+3
AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207165
2014-04-25Revert "Debug info for optimized code: Support variables that are on the ↵Adrian Prantl1-3/+3
stack and" This reverts commit 207130 for buildbot breakage. llvm-svn: 207162
2014-04-24Debug info for optimized code: Support variables that are on the stack andAdrian Prantl1-3/+3
described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine-intrinsics testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207130
2014-04-22[Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth1-1/+2
define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
2014-04-21Use unique_ptr to handle ownership of UserValues in LiveDebugVariablesImplDavid Blaikie1-4/+6
llvm-svn: 206785
2014-04-14[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-9/+9
instead of comparing to nullptr. llvm-svn: 206142
2014-03-17Switch a number of loops in lib/CodeGen over to range-based for-loops, now thatOwen Anderson1-5/+3
the MachineRegisterInfo iterators are compatible with it. llvm-svn: 204075
2014-03-13Phase 2 of the great MachineRegisterInfo cleanup. This time, we're changingOwen Anderson1-2/+2
operator* on the by-operand iterators to return a MachineOperand& rather than a MachineInstr&. At this point they almost behave like normal iterators! Again, this requires making some existing loops more verbose, but should pave the way for the big range-based for-loop cleanups in the future. llvm-svn: 203865
2014-03-06[Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth1-1/+1
already lives. llvm-svn: 203046
2014-03-02[C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer1-2/+2
Remove the old functions. llvm-svn: 202636
2013-11-20Remove capability for polymorphic destruction from LexicalScopeEric Christopher1-1/+0
and LexicalScopes, we're not using it. llvm-svn: 195182
generated by cgit v1.1 at 2025-10-03 08:13:23 +0000