aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/LiveDebugVariables.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-02-13[CodeGen] Use range-based for loops (NFC)Kazu Hirata1-7/+5
2021-01-28[LiveDebugVariables] Add cache for SkipPHIsLabelsAndDebug to preventWei Mi1-20/+64
iterating the same PHI/LABEL/Debug instructions repeatedly. We run into a compiling timeout problem when building a target after its SampleFDO profile is updated. It is because some very large blocks with a bunch of PHIs at the beginning. LiveDebugVariables::emitDebugValues called during VirtRegRewriter phase searchs the insertion point for those large BBs repeatedly in SkipPHIsLabelsAndDebug, and each time SkipPHIsLabelsAndDebug needs to go through the same set of PHIs before it can find the first non PHI/Label/Debug instruction. This patch adds a cache to save the last position for the sequence which has been checked in the previous call of SkipPHIsLabelsAndDebug. Differential Revision: https://reviews.llvm.org/D94981
2020-11-26[LiveDebugVariables] Strip all debug instructions from nodebug functionsRobert Lougher1-3/+3
A crash/assertion failure in the greedy register allocator was tracked down to a debug instr being passed to LiveIntervals::getInstructionIndex. Normally this should not occur as debug instructions are collected and removed by LiveDebugVariables before RA, and reinserted afterwards. However, when a function has no debug info, LiveDebugVariables simply strips any debug values that are present as they're not needed (this situation will occur when a function with debug info is inlined into a nodebug function). The problem is, it only removes DBG_VALUE instructions, leaving DBG_LABELs (the cause of the crash). This patch updates the LiveDebugVariables nodebug path to remove all debug instructions. The test case verifies that DBG_VALUE/DBG_LABEL instructions are present, and that they are stripped. When -experimental-debug-variable-locations is enabled, certain variable locations are represented by DBG_INSTR_REF instead of DBG_VALUE. The test case verifies that a DBG_INSTR_REF is emitted by the option, and that it is also stripped. Differential Revision: https://reviews.llvm.org/D92127
2020-10-22[DebugInstrRef] Pass DBG_INSTR_REFs through register allocationJeremy Morse1-0/+52
Both FastRegAlloc and LiveDebugVariables/greedy need to cope with DBG_INSTR_REFs. None of them actually need to take any action, other than passing DBG_INSTR_REFs through: variable location information doesn't refer to any registers at this stage. LiveDebugVariables stashes the instruction information in a tuple, then re-creates it later. This is only necessary as the register allocator doesn't expect to see any debug instructions while it's working. No equivalence classes or interval splitting is required at all! No changes are needed for the fast register allocator, as it just ignores debug instructions. The test added checks that both of them preserve DBG_INSTR_REFs. This also expands ScheduleDAGInstrs.cpp to treat DBG_INSTR_REFs the same as DBG_VALUEs when rescheduling instructions around. The current movement of DBG_VALUEs around is less than ideal, but it's not a regression to make DBG_INSTR_REFs subject to the same movement. Differential Revision: https://reviews.llvm.org/D85757
2020-09-17LiveDebugVariables.cpp - remove unnecessary Compiler.h include. NFCI.Simon Pilgrim1-1/+0
Already included in LiveDebugVariables.h
2020-09-16[NFC][Regalloc] accessors for 'reg' and 'weight'Mircea Trofin1-3/+3
Also renamed the fields to follow style guidelines. Accessors help with readability - weight mutation, in particular, is easier to follow this way. Differential Revision: https://reviews.llvm.org/D87725
2020-09-04[LiveDebugVariables] Delete unneeded doInitializationFangrui Song1-4/+0
2020-08-23[LiveDebugVariables] Internalize class DbgVariableValue. NFCFangrui Song1-0/+2
2020-06-30RegAlloc: Start using RegisterMatt Arsenault1-11/+11
2020-06-22[DebugInfo] Update MachineInstr to help support variadic DBG_VALUE instructionsstozer1-8/+9
Following on from this RFC[0] from a while back, this is the first patch towards implementing variadic debug values. This patch specifically adds a set of functions to MachineInstr for performing operations specific to debug values, and replacing uses of the more general functions where appropriate. The most prevalent of these is replacing getOperand(0) with getDebugOperand(0) for debug-value-specific code, as the operands corresponding to values will no longer be at index 0, but index 2 and upwards: getDebugOperand(x) == getOperand(x+2). Similar replacements have been added for the other operands, along with some helper functions to replace oft-repeated code and operate on a variable number of value operands. [0] http://lists.llvm.org/pipermail/llvm-dev/2020-February/139376.html<Paste> Differential Revision: https://reviews.llvm.org/D81852
2020-04-02[NFC] Fix performance issue in LiveDebugVariablesOCHyams1-35/+12
When compiling AMDGPUDisassembler.cpp in a stage 1 trunk build with CMAKE_BUILD_TYPE=RelWithDebInfo LLVM_USE_SANITIZER=Address LiveDebugVariables accounts for 21.5% wall clock time. This fix reduces that to 1.2% by switching out a linked list lookup with a map lookup. Note that the linked list is still used to group UserValues by vreg. The vreg lookups don't cause any problems in this pathological case. This is the same idea as D68816, which was reverted, except that it is a less intrusive fix. Reviewed By: vsk Differential Revision: https://reviews.llvm.org/D77226
2020-02-11[DebugInfo][NFC] Fixup the UserValue methods to use FragmentInfoOCHyams1-18/+19
Fixup the UserValue methods to use FragmentInfo instead of DIExpression because the DIExpression is only ever used to get the to get the FragmentInfo. The DIExpression is meaningless in the UserValue class because each definition point added to a UserValue may have a unique DIExpression. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D74057
2020-02-11[DebugInfo][NFC] Rename the class DbgValueLocation to DbgVariableValueOCHyams1-87/+93
Rename the class DbgValueLocation to DbgVariableValue and instances from Loc to DbgValue. These names better express the new semantics introduced in D74053. The class previously represented a { Location } only. It now represents a { Location, DIExpression } pair which together describe a value. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D74055
2020-02-11[DebugInfo] Teach LDV how to handle identical variable fragmentsOCHyams1-23/+37
LiveDebugVariables uses interval maps to explicitly represent DBG_VALUE intervals. DBG_VALUEs are filtered into an interval map based on their { Variable, DIExpression }. The interval map will coalesce adjacent entries that use the same { Location }. Under this model, DBG_VALUEs which refer to the same bits of the same variable will be filtered into different interval maps if they have different DIExpressions which means the original intervals will not be properly preserved. This patch fixes the problem by using { Variable, Fragment } to filter the DBG_VALUEs into maps, and coalesces adjacent entries iff they have the same { Location, DIExpression } pair. The solution is not perfect because we see the similar issues appear when partially overlapping fragments are encountered, but is far simpler than a complete solution (i.e. D70121). Fixes: pr41992, pr43957 Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D74053
2020-02-06Revert "[DebugInfo] Remove some users of DBG_VALUEs IsIndirect field"Jeremy Morse1-19/+33
This reverts commit ed29dbaafa49bb8c9039a35f768244c394411fea. I'm backing out D68945, which as the discussion for D73526 shows, doesn't seem to handle the -O0 path through the codegen backend correctly. I'll reland the patch when a fix is worked out, apologies for all the churn. The two parent commits are part of this revert too. Conflicts: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp llvm/test/DebugInfo/X86/dbg-addr-dse.ll SelectionDAGBuilder conflict is due to a nearby change in e39e2b4a79c6 that's technically unrelated. dbg-addr-dse.ll conflicted because 41206b61e30c (legitimately) changes the order of two lines. There are further modifications to dbg-value-func-arg.ll: it landed after the patch being reverted, and I've converted indirection to be represented by the isIndirect field rather than DW_OP_deref.
2020-02-06Revert "[SafeStack][DebugInfo] Insert DW_OP_deref in correct location"Jeremy Morse1-2/+2
This reverts commit 2d3174c4df6b5f4131346828d0a31675d80d6e2b. The overall solution for this problem is reverting D68945, which wasn't handling the -O0 path through the codegen backend correctly. See: discussion in D73526.
2020-02-04[DebugInfo] Re-instate LiveDebugVariables scope trimmingJeremy Morse1-1/+24
This patch reverts part of r362750 / D62650, which stopped LiveDebugVariables from trimming leading variable location ranges down to only covering those instructions that are in scope. I've observed some circumstances where the number of DBG_VALUEs in a function can be amplified in an un-necessary way, to cover more instructions that are out of scope, leading to very slow compile times. Trimming the range of instructions that the variables cover solves the slow compile times. The specific problem that r362750 tries to fix is addressed by the assignment to RStart that I've added. Any variable location that begins at the first instruction of a block will now be considered to begin at the start of the block. While these sound the same, the have different SlotIndexes, and the register allocator may shoehorn additional instructions in between the two. The test added in the past (wrong_debug_loc_after_regalloc.ll) still works with this modification. live-debug-variables.ll has a range trimmed to not cover the prologue of the function, while dbg-addr-dse.ll has a DBG_VALUE sink past one instruction with no DebugLoc, which is expected behaviour. Differential Revision: https://reviews.llvm.org/D73691
2020-01-30[SafeStack][DebugInfo] Insert DW_OP_deref in correct locationLeonard Chan1-2/+2
This patch addresses the issue found in https://bugs.llvm.org/show_bug.cgi?id=44585 where a DW_OP_deref was placed at the end of a dwarf expression, resulting in corrupt symbols when debugging. This is an attempt to reland with a few fixes for buildbot since I haven't merged from master in a bit. Differential Revision: https://reviews.llvm.org/D73526
2020-01-06Fix "use of uninitialized variable" static analyzer warning. NFCI.Simon Pilgrim1-1/+1
2019-11-13Sink all InitializePasses.h includesReid Kleckner1-0/+1
This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
2019-11-01[LDV][RAGreedy] Inform LiveDebugVariables about new VRegs added by InlineSpillerBjorn Pettersson1-17/+27
Summary: Make sure RAGreedy informs LiveDebugVariables about new VRegs that is introduced at spill by InlineSpiller. Consider this example LDV: !"var" [48r;128r):0 Loc0=%2 48B %2 = ... ... 128B %7 = ADD %2, ... If %2 is spilled the InlineSpiller will insert spill/reload instructions and introduces some new vregs. So we get 48B %4 = ... 56B spill %4 ... 120B reload %5 128B %3 = ADD %5, ... In the past we did not inform LDV about this, and when reintroducing DBG_VALUE instruction LDV still got information that "var" had the location of the spilled register %2 for the interval [48r;128r). The result was bad, since we mapped "var" to the spill slot even before the spill happened: %4 = ... DBG_VALUE %spill.0, !"var" spill %4 to %spill.0 ... reload %5 %3 = ADD %5, ... This patch will inform LDV about the interval split introduced due to spilling. So the location map in LDV will become !"var" [48r;56r):1 [56r;120r):0 [120r;128r):2 Loc0=%2 Loc1=%4 Loc2=%5 And when inserting DBG_VALUE instructions we get %4 = ... DBG_VALUE %4, !"var" spill %4 to %spill.0 DBG_VALUE %spill.0, !"var" ... reload %5 DBG_VALUE %5, !"var" %3 = ADD %5, ... Fixes: https://bugs.llvm.org/show_bug.cgi?id=38899 Reviewers: jmorse, vsk, aprantl Reviewed By: jmorse Subscribers: dstenb, wuzish, MatzeB, qcolombet, nemanjai, hiraditya, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69584
2019-10-29Revert "[NFC] Replace a linked list in LiveDebugVariables pass with a DenseMap"Andrea Di Biagio1-97/+82
This reverts commit 8af5ada09319e5a021d57a1a03715b2fd022e415. As Bjorn pointed out in D68816, the iteration over `UserVals` may not be safe. Reverting on behalf of Orlando.
2019-10-16[NFC] Replace a linked list in LiveDebugVariables pass with a DenseMapOrlando Cazalet-Hyams1-82/+97
In LiveDebugVariables.cpp: Prior to this patch, UserValues were grouped into linked list chains. Each chain was the union of two sets: { A: Matching Source variable } or { B: Matching virtual register }. A ptr to the heads (or 'leaders') of each of these chains were kept in a map with the { Source variable } used as the key (set A predicate) and another with { Virtual register } as key (set B predicate). There was a search through the chains in the function getUserValue looking for UserValues with matching { Source variable, Complex expression, Inlined-at location }. Essentially searching for a subset of A through two interleaved linked lists of set A and B. Importantly, by design, the subset will only contain one or zero elements here. That is to say a UserValue can be uniquely identified by the tuple { Source variable, Complex expression, Inlined-at location } if it exists. This patch removes the linked list and instead uses a DenseMap to map the tuple { Source variable, Complex expression, Inlined-at location } to UserValue ptrs so that the getUserValue search predicate is this map key. The virtual register map now maps a vreg to a SmallVector<UserVal *> so that set B is still available for quick searches. Reviewers: aprantl, probinson, vsk, dblaikie Reviewed By: aprantl Subscribers: russell.gallop, gbedwell, bjope, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D68816 llvm-svn: 374979
2019-10-15[DebugInfo] Remove some users of DBG_VALUEs IsIndirect fieldJeremy Morse1-33/+19
This patch kills off a significant user of the "IsIndirect" field of DBG_VALUE machine insts. Brought up in in PR41675, IsIndirect is techncally redundant as it can be expressed by the DIExpression of a DBG_VALUE inst, and it isn't helpful to have two ways of expressing things. Rather than setting IsIndirect, have DBG_VALUE creators add an extra deref to the insts DIExpression. There should now be no appearences of IsIndirect=True from isel down to LiveDebugVariables / VirtRegRewriter, which is ensured by an assertion in LDVImpl::handleDebugValue. This means we also get to delete the IsIndirect handling in LiveDebugVariables. Tests can be upgraded by for example swapping the following IsIndirect=True DBG_VALUE: DBG_VALUE $somereg, 0, !123, !DIExpression(DW_OP_foo) With one where the indirection is in the DIExpression, by _appending_ a deref: DBG_VALUE $somereg, $noreg, !123, !DIExpression(DW_OP_foo, DW_OP_deref) Which both mean the same thing. Most of the test changes in this patch are updates of that form; also some changes in how the textual assembly printer handles these insts. Differential Revision: https://reviews.llvm.org/D68945 llvm-svn: 374877
2019-08-15Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders1-4/+4
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Partial reverts in: X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned& MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register PPCFastISel.cpp - No Register::operator-=() PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned& MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor Manual fixups in: ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned& HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register. PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned& Depends on D65919 Reviewers: arsenm, bogner, craig.topper, RKSimon Reviewed By: arsenm Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65962 llvm-svn: 369041
2019-08-15[llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-2/+2
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
2019-08-01Finish moving TargetRegisterInfo::isVirtualRegister() and friends to ↵Daniel Sanders1-8/+8
llvm::Register as started by r367614. NFC llvm-svn: 367633
2019-07-12Delete dead storesFangrui Song1-3/+1
llvm-svn: 365903
2019-06-06[DebugInfo] Incorrect debug info record generated for loop counter.Alexey Lapshin1-19/+1
Incorrect Debug Variable Range was calculated while "COMPUTING LIVE DEBUG VARIABLES" stage. Range for Debug Variable("i") computed according to current state of instructions inside of basic block. But Register Allocator creates new instructions which were not taken into account when Live Debug Variables computed. In the result DBG_VALUE instruction for the "i" variable was put after these newly inserted instructions. This is incorrect. Debug Value for the loop counter should be inserted before any loop instruction. Differential Revision: https://reviews.llvm.org/D62650 llvm-svn: 362750
2019-05-20[DebugInfoMetadata] Refactor DIExpression::prepend constants (NFC)Petar Jovanovic1-2/+4
Refactor DIExpression::With* into a flag enum in order to be less error-prone to use (as discussed on D60866). Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D61943 llvm-svn: 361137
2019-05-09Bugfix for nullptr check by klocworkPengfei Wang1-1/+2
Klocwork static check: Pointer from call to function `DebugLoc::operator DILocation *() const ` may be NULL and will be dereference in function `printExtendedName``` Patch by Shengchen Kan (skan) Differential Revision: https://reviews.llvm.org/D61715 llvm-svn: 360317
2019-04-12Include what's used in a few cpp files - these were getting transitiveEric Christopher1-0/+1
includes from MCDwarf.h. llvm-svn: 358254
2019-02-23[NFC] Fix typos: preceeding -> precedingJordan Rupprecht1-1/+1
llvm-svn: 354715
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-18[CodeGen] Fix bugs in LiveDebugVariables when debug labels are generated.Hsiangkai Wang1-13/+125
Remove DBG_LABELs in LiveDebugVariables and generate them in VirtRegRewriter. This bug is reported in https://bugs.chromium.org/p/chromium/issues/detail?id=898152. Differential Revision: https://reviews.llvm.org/D54465 llvm-svn: 351525
2018-11-30[NFC] Refine doxygen format.Hsiangkai Wang1-57/+64
Differential Revision: https://reviews.llvm.org/D54568 llvm-svn: 347963
2018-09-07[DebugInfo] Handle stack slot offsets for spilled sub-registers in LDVDavid Stenberg1-30/+57
Summary: Extend LDV so that stack slot offsets for spilled sub-registers are added to the emitted debug locations. This is accomplished by querying InstrInfo::getStackSlotRange(). With this change, LDV will add a DW_OP_plus_uconst operation to the expression if a sub-register is spilled. Later on, PEI will add an offset operation for the stack slot, meaning that we will get expressions of the forms: * {DW_OP_constu #fp-offset, DW_OP_minus, DW_OP_plus_uconst #subreg-offset} * {DW_OP_plus_const #fp-offset, DW_OP_minus, DW_OP_plus_uconst #subreg-offset} The two offset operations should ideally be merged. Reviewers: rnk, aprantl, stoklund Reviewed By: aprantl Subscribers: dblaikie, bjope, nemanjai, JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D51612 llvm-svn: 341659
2018-09-05[DebugInfo] Fix bug in LiveDebugVariables.Hsiangkai Wang1-5/+10
In lib/CodeGen/LiveDebugVariables.cpp, it uses std::prev(MBBI) to get DebugValue's SlotIndex. However, the previous instruction may be also a debug instruction. It could not use a debug instruction to query SlotIndex in mi2iMap. Scan all debug instructions and use the first debug instruction to query SlotIndex for following debug instructions. Only handle DBG_VALUE in handleDebugValue(). Differential Revision: https://reviews.llvm.org/D50621 llvm-svn: 341446
2018-09-02Revert "[DebugInfo] Fix bug in LiveDebugVariables."Hsiangkai Wang1-10/+5
This reverts commit 8f548ff2a1819e1bc051e8218584f1a3d2cf178a. buildbot failure in LLVM on clang-ppc64be-linux http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/19765 llvm-svn: 341290
2018-09-02[DebugInfo] Fix bug in LiveDebugVariables.Hsiangkai Wang1-5/+10
In lib/CodeGen/LiveDebugVariables.cpp, it uses std::prev(MBBI) to get DebugValue's SlotIndex. However, the previous instruction may be also a debug instruction. It could not use a debug instruction to query SlotIndex in mi2iMap. Scan all debug instructions and use the first debug instruction to query SlotIndex for following debug instructions. Only handle DBG_VALUE in handleDebugValue(). Differential Revision: https://reviews.llvm.org/D50621 llvm-svn: 341289
2018-08-25[LiveDebugVariables] Avoid faulty addDefsFromCopies in computeIntervalsBjorn Pettersson1-1/+9
Summary: When computeIntervals is looking through COPY instruction to extend the location mapping for a debug variable it did not handle subregisters correctly. For example DBG_VALUE debug-use %0.sub_8bit_hi, ... %1:gr16 = COPY %0 was transformed into DBG_VALUE debug-use %0.sub_8bit_hi, ... %1:gr16 = COPY %0 DBG_VALUE debug-use %1, ... So the subregister index was missing in the added DBG_VALUE. As long as the subreg refered to the least significant bits of the superreg, then I guess we could get the correct result in a debugger even when referring to the superreg. But as in the example above when the subreg refers to other parts of the superreg, then debuginfo would be incorrect. I'm not sure exactly how to fix this properly, so this patch just avoids looking through the COPY when there is a subreg involved (for more info, see the FIXME added in the code). Reviewers: rnk, aprantl Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D50788 llvm-svn: 340679
2018-08-23Revert r340508: [DebugInfo] Fix bug in LiveDebugVariables.Chandler Carruth1-10/+5
This patch's test case relies on debug prints which isn't generally an OK way to test stuff in LLVM and fails whenever asserts aren't enabled. I've send a heads-up to the commit and detailed comments on the review. llvm-svn: 340513
2018-08-23[DebugInfo] Fix bug in LiveDebugVariables.Hsiangkai Wang1-5/+10
In lib/CodeGen/LiveDebugVariables.cpp, it uses std::prev(MBBI) to get DebugValue's SlotIndex. However, the previous instruction may be also a debug instruction. It could not use a debug instruction to query SlotIndex in mi2iMap. Scan all debug instructions and use the first debug instruction to query SlotIndex for following debug instructions. Only handle DBG_VALUE in handleDebugValue(). Differential Revision: https://reviews.llvm.org/D50621 llvm-svn: 340508
2018-07-16[CodeGen] Fix inconsistent declaration parameter nameFangrui Song1-1/+1
llvm-svn: 337200
2018-06-21[DebugInfo] Make sure all DBG_VALUEs' reguse operands have IsDebug propertyMikael Holmen1-8/+2
Summary: In some cases, these operands lacked the IsDebug property, which is meant to signal that they should not affect codegen. This patch adds a check for this property in the MachineVerifier and adds it where it was missing. This includes refactorings to use MachineInstrBuilder construction functions instead of manually setting up the intrinsic everywhere. Patch by: JesperAntonsson Reviewers: aprantl, rnk, echristo, javed.absar Reviewed By: aprantl Subscribers: qcolombet, sdardis, nemanjai, JDevlieghere, atanasyan, llvm-commits Differential Revision: https://reviews.llvm.org/D48319 llvm-svn: 335214
2018-06-21[DebugInfo] Keep DBG_VALUE undef in LiveDebugVariablesMikael Holmen1-10/+22
Summary: Fixes PR36579. For cases where we had e.g. DBG_VALUE 42 [...] DBG_VALUE undef LiveDebugVariables would discard all undef DBG_VALUEs and then it would look like the variable had the value 42 throughout the rest of the function, which is incorrect. With this patch we don't remove all undef DBG_VALUEs in LiveDebugVariables so they will be kept after register allocation just like other DBG_VALUEs which will yield more correct debug information. Reviewers: aprantl Reviewed By: aprantl Subscribers: bjope, Ka-Ka, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D48277 llvm-svn: 335205
2018-05-14Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen1-21/+25
The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
2018-04-30IWYU for llvm-config.h in llvm, additions.Nico Weber1-0/+1
See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
2018-03-06Fixup for rL326769 (RegState::Debug is being truncated to a bool)Bjorn Pettersson1-2/+5
I obviously messed up arguments to MachineOperand::CreateReg in rL326769. This should make it work as intended. Thanks to RKSimon for spotting this. llvm-svn: 326780
2018-03-06[DebugInfo] Discard invalid DBG_VALUE instructions in LiveDebugVariablesBjorn Pettersson1-1/+37
Summary: This is a workaround for pr36417 https://bugs.llvm.org/show_bug.cgi?id=36417 LiveDebugVariables will now verify that the DBG_VALUE instructions are sane (prior to register allocation) by asking LIS if a virtual register used in the DBG_VALUE is live (or dead def) in the slot index before the DBG_VALUE. If it isn't sane the DBG_VALUE is discarded. One pass that was identified as introducing non-sane DBG_VALUE instructtons, when analysing pr36417, was the DAG->DAG Instruction Selection. It sometimes inserts DBG_VALUE instructions referring to a virtual register that is defined later in the same basic block. So it is a use before def kind of problem. The DBG_VALUE is typically inserted in the beginning of a basic block when this happens. The problem can be seen in the test case test/DebugInfo/X86/dbg-value-inlined-parameter.ll Reviewers: aprantl, rnk, probinson Reviewed By: aprantl Subscribers: vsk, davide, alexcrichton, Ka-Ka, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D43956 llvm-svn: 326769
generated by cgit v1.1 at 2025-09-29 15:28:26 +0000