summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* Changing CodeView debug info type record representation in assembly files to ↵Nilanjana Basu2019-07-0938-14/+405
| | | | | | make it more human-readable & editable & fixing bug introduced in r364987 llvm-svn: 365417
* Revert Changing CodeView debug info type record representation in assembly ↵Nilanjana Basu2019-07-0338-405/+14
| | | | | | | | files to make it more human-readable & editable This reverts r364982 (git commit 2082bf28ebea76cc187b508f801122866420d9ff) llvm-svn: 364987
* Changing CodeView debug info type record representation in assembly files to ↵Nilanjana Basu2019-07-0338-14/+405
| | | | | | make it more human-readable & editable llvm-svn: 364982
* Use --defsym instead of sed in a test. NFCPaul Robinson2019-07-021-22/+40
| | | | llvm-svn: 364929
* [DebugInfo] Avoid adding too much indirection to pointer-valued variablesJeremy Morse2019-07-011-0/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch addresses PR41675, where a stack-pointer variable is dereferenced too many times by its location expression, presenting a value on the stack as the pointer to the stack. The difference between a stack *pointer* DBG_VALUE and one that refers to a value on the stack, is currently the indirect flag. However the DWARF backend will also try to guess whether something is a memory location or not, based on whether there is any computation in the location expression. By simply prepending the stack offset to existing expressions, we can accidentally convert a register location into a memory location, which introduces a suprise (and unintended) dereference. The solution is to add DW_OP_stack_value whenever we add a DIExpression computation to a stack *pointer*. It's an implicit location computed on the expression stack, thus needs to be flagged as a stack_value. For the edge case where the offset is zero and the location could be a register location, DIExpression::prepend will still generate opcodes, and thus DW_OP_stack_value must still be added. Differential Revision: https://reviews.llvm.org/D63429 llvm-svn: 364736
* Revert "[LiveDebugValues] Emit the debug entry values"Djordje Todorovic2019-06-272-162/+0
| | | | | | | | | Appears that the 'test/DebugInfo/MIR/X86/dbginfo-entryvals.mir' does not pass on Windows. This reverts commit rL364553. llvm-svn: 364571
* [LiveDebugValues] Emit the debug entry valuesDjordje Todorovic2019-06-272-0/+162
| | | | | | | | | | | | | | | | Emit replacements for clobbered parameters location if the parameter has unmodified value throughout the funciton. This is basic scenario where we can use the debug entry values. ([12/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D58042 llvm-svn: 364553
* Add triple to a test I just added.Jeremy Morse2019-06-271-1/+1
| | | | llvm-svn: 364524
* [DebugInfo] Avoid register coalesing unsoundly changing DBG_VALUE locationsJeremy Morse2019-06-271-0/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Once MIR code leaves SSA form and the liveness of a vreg is considered, DBG_VALUE insts are able to refer to non-live vregs, because their debug-uses do not contribute to liveness. This non-liveness becomes problematic for optimizations like register coalescing, as they can't ``see'' the debug uses in the liveness analyses. As a result registers get coalesced regardless of debug uses, and that can lead to invalid variable locations containing unexpected values. In the added test case, the first vreg operand of ADD32rr is merged with various copies of the vreg (great for performance), but a DBG_VALUE of the unmodified operand is blindly updated to the modified operand. This changes what value the variable will appear to have in a debugger. Fix this by changing any DBG_VALUE whose operand will be resurrected by register coalescing to be a $noreg DBG_VALUE, i.e. give the variable no location. This is an overapproximation as some coalesced locations are safe (others are not) -- an extra domination analysis would be required to work out which, and it would be better if we just don't generate non-live DBG_VALUEs. This fixes PR40010. Differential Revision: https://reviews.llvm.org/D56151 llvm-svn: 364515
* [WebAssembly] Implement tail calls and unify tablegen call classesThomas Lively2019-06-261-4/+4
| | | | | | | | | | | | | | | | | Summary: Implements direct and indirect tail calls enabled by the 'tail-call' feature in both DAG ISel and FastISel. Updates existing call tests and adds new tests including a binary encoding test. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62877 llvm-svn: 364445
* Store a pointer to the return value in a static alloca and let the debugger ↵Amy Huang2019-06-201-0/+144
| | | | | | | | | | | | | | use that as the variable address for NRVO variables. Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63361 llvm-svn: 363952
* [llvm-dwarfdump] --gdb-index: fix uninitialized TuListOffsetFangrui Song2019-06-191-0/+2
| | | | | | | | | | | | The test only checks the existence of the `Types CU list` line. Unfortunately I can't make a better test because {gcc,clang} -fuse-ld={lld,gold} --gdb-index do not give me a non-empty types CU list. Reviewed By: ikudrin Differential Revision: https://reviews.llvm.org/D63537 llvm-svn: 363800
* [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through ↵Orlando Cazalet-Hyams2019-06-191-73/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 > llvm-svn: 363046 llvm-svn: 363786
* Rename ExpandISelPseudo->FinalizeISel, delay register reservationMatt Arsenault2019-06-1915-15/+15
| | | | | | | | | | | This allows targets to make more decisions about reserved registers after isel. For example, now it should be certain there are calls or stack objects in the frame or not, which could have been introduced by legalization. Patch by Matthias Braun llvm-svn: 363757
* [lit] Delete empty lines at the end of lit.local.cfg NFCFangrui Song2019-06-178-8/+0
| | | | llvm-svn: 363538
* Describe stack-id as an enumSander de Smalen2019-06-1717-99/+99
| | | | | | | | | | | | | | | | | This patch changes MIR stack-id from an integer to an enum, and adds printing/parsing support for this in MIR files. The default stack-id '0' is now renamed to 'default'. This should make MIR tests that have stack objects with different stack-ids more descriptive. It also clarifies code operating on StackID. Reviewers: arsenm, thegameg, qcolombet Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D60137 llvm-svn: 363533
* [MBP] Move a latch block with conditional exit and multi predecessors to top ↵Guozhi Wei2019-06-142-12/+13
| | | | | | | | | | | | | | | | of loop Current findBestLoopTop can find and move one kind of block to top, a latch block has one successor. Another common case is: * a latch block * it has two successors, one is loop header, another is exit * it has more than one predecessors If it is below one of its predecessors P, only P can fall through to it, all other predecessors need a jump to it, and another conditional jump to loop header. If it is moved before loop header, all its predecessors jump to it, then fall through to loop header. So all its predecessors except P can reduce one taken branch. Differential Revision: https://reviews.llvm.org/D43256 llvm-svn: 363471
* DebugInfo: Include enumerators in pubnamesDavid Blaikie2019-06-141-147/+219
| | | | | | | | | | | This is consistent with GCC's behavior (which is the defacto standard for pubnames). Though I find the presence of enumerators from enum classes to be a bit confusing, possibly a bug on GCC's end (since they can't be named unqualified, unlike the other names - and names nested in classes don't go in pubnames, for instance - presumably because one must name the class first & that's enough to limit the scope of the search) llvm-svn: 363349
* [X86] Add target triple for live-debug-values-fragments.mirTim Shen2019-06-141-0/+1
| | | | llvm-svn: 363348
* Use fully qualified name when printing S_CONSTANT recordsAmy Huang2019-06-131-56/+94
| | | | | | | | | | | | | | | | Summary: Before it was using the fully qualified name only for static data members. Now it does for all variable names to match MSVC. Reviewers: rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63012 llvm-svn: 363335
* [GlobalISel][IRTranslator] Add debug loc with line 0 to constants emitted ↵Amara Emerson2019-06-131-1/+1
| | | | | | | | | | | | | | | into the entry block. Constants, including G_GLOBAL_VALUE, are all emitted into the entry block which lets us use the vreg def assuming it dominates all other users. However, it can cause jumpy debug behaviour since the DebugLoc attached to these MIs are from a user instruction that could be in a different block. Fixes PR40887. Differential Revision: https://reviews.llvm.org/D63286 llvm-svn: 363331
* [DebugInfo] Honour variable fragments in LiveDebugValuesJeremy Morse2019-06-132-24/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes the LiveDebugValues pass consider fragments when propagating DBG_VALUE insts between blocks, fixing PR41979. Fragment info for a variable location is added to the open-ranges key, which allows distinct fragments to be tracked separately. To handle overlapping fragments things become slightly funkier. To avoid excessive searching for overlaps in the data-flow part of LiveDebugValues, this patch: * Pre-computes pairings of fragments that overlap, for each DILocalVariable * During data-flow, whenever something happens that causes an open range to be terminated (via erase), any fragments pre-determined to overlap are also terminated. The effect of which is that when encountering a DBG_VALUE fragment that overlaps others, the overlapped fragments do not get propagated to other blocks. We still rely on later location-list building to correctly handle overlapping fragments within blocks. It's unclear whether a mixture of DBG_VALUEs with and without fragmented expressions are legitimate. To avoid suprises, this patch interprets a DBG_VALUE with no fragment as overlapping any DBG_VALUE _with_ a fragment. Differential Revision: https://reviews.llvm.org/D62904 llvm-svn: 363256
* [DebugInfo] Use FrameDestroy to extend stack locations to end-of-functionJeremy Morse2019-06-134-19/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | We aim to ignore changes in variable locations during the prologue and epilogue of functions, to avoid using space documenting location changes that aren't visible. However in D61940 / r362951 this got ripped out as the previous implementation was unsound. Instead, use the FrameDestroy flag to identify when we're in the epilogue of a function, and ignore variable location changes accordingly. This fits in with existing code that examines the FrameSetup flag. Some variable locations get shuffled in modified tests as they now cover greater ranges, which is what would be expected. Some additional single-location variables are generated too. Two tests are un-xfailed, they were only xfailed due to r362951 deleting functionality they depended on. Apparently some out-of-tree backends don't accurately maintain FrameDestroy flags -- if you're an out-of-tree maintainer and see changes in variable locations disappear due to a faulty FrameDestroy flag, it's safe to back this change out. The impact is just slightly more debug info than necessary. Differential Revision: https://reviews.llvm.org/D62314 llvm-svn: 363245
* [DebugInfo] Add a test that fell out of an earlier commitJeremy Morse2019-06-121-0/+347
| | | | | | | r362951 was supposed to contain this test, however it didn't get committed due to operator error. This was originally part of D59431. llvm-svn: 363161
* Revert "[DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step ↵Orlando Cazalet-Hyams2019-06-121-76/+73
| | | | | | | | | through loop even after completion" This reverts commit 1a0f7a2077b70c9864faa476e15b048686cf1ca7. See phabricator thread for D60831. llvm-svn: 363132
* [DebugInfo@O2][LoopVectorize] pr39024: Vectorized code linenos step through ↵Orlando Cazalet-Hyams2019-06-111-73/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | loop even after completion Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=39024 The bug reports that a vectorized loop is stepped through 4 times and each step through the loop seemed to show a different path. I found two problems here: A) An incorrect line number on a preheader block (for.body.preheader) instruction causes a step into the loop before it begins. B) Instructions in the middle block have different line numbers which give the impression of another iteration. In this patch I give all of the middle block instructions the line number of the scalar loop latch terminator branch. This seems to provide the smoothest debugging experience because the vectorized loops will always end on this line before dropping into the scalar loop. To solve problem A I have altered llvm::SplitBlockPredecessors to accommodate loop header blocks. I have set up a separate review D61933 for a fix which is required for this patch. Reviewers: samsonov, vsk, aprantl, probinson, anemet, hfinkel, jmorse Reviewed By: hfinkel, jmorse Subscribers: jmorse, javed.absar, eraman, kcc, bjope, jmellorcrummey, hfinkel, gbedwell, hiraditya, zzheng, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D60831 llvm-svn: 363046
* [FastISel] Skip creating unnecessary vregs for argumentsFrancis Visoiu Mistrih2019-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This behavior was added in r130928 for both FastISel and SD, and then disabled in r131156 for FastISel. This re-enables it for FastISel with the corresponding fix. This is triggered only when FastISel can't lower the arguments and falls back to SelectionDAG for it. FastISel contains a map of "register fixups" where at the end of the selection phase it replaces all uses of a register with another register that FastISel sometimes pre-assigned. Code at the end of SelectionDAGISel::runOnMachineFunction is doing the replacement at the very end of the function, while other pieces that come in before that look through the MachineFunction and assume everything is done. In this case, the real issue is that the code emitting COPY instructions for the liveins (physreg to vreg) (EmitLiveInCopies) is checking if the vreg assigned to the physreg is used, and if it's not, it will skip the COPY. If a register wasn't replaced with its assigned fixup yet, the copy will be skipped and we'll end up with uses of undefined registers. This fix moves the replacement of registers before the emission of copies for the live-ins. The initial motivation for this fix is to enable tail calls for swiftself functions, which were blocked because we couldn't prove that the swiftself argument (which is callee-save) comes from a function argument (live-in), because there was an extra copy (vreg to vreg). A few tests are affected by this: * llvm/test/CodeGen/AArch64/swifterror.ll: we used to spill x21 (callee-save) but never reload it because it's attached to the return. We now don't even spill it anymore. * llvm/test/CodeGen/*/swiftself.ll: we tail-call now. * llvm/test/CodeGen/AMDGPU/mubuf-legalize-operands.ll: I believe this test was not really testing the right thing, but it worked because the same registers were re-used. * llvm/test/CodeGen/ARM/cmpxchg-O0.ll: regalloc changes * llvm/test/CodeGen/ARM/swifterror.ll: get rid of a copy * llvm/test/CodeGen/Mips/*: get rid of spills and copies * llvm/test/CodeGen/SystemZ/swift-return.ll: smaller stack * llvm/test/CodeGen/X86/atomic-unordered.ll: smaller stack * llvm/test/CodeGen/X86/swifterror.ll: same as AArch64 * llvm/test/DebugInfo/X86/dbg-declare-arg.ll: stack size changed Differential Revision: https://reviews.llvm.org/D62361 llvm-svn: 362963
* [DebugInfo] Terminate all location-lists at end of blockJeremy Morse2019-06-1010-24/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit reapplies r359426 (which was reverted in r360301 due to performance problems) and rolls in D61940 to address the performance problem. I've combined the two to avoid creating a span of slow-performance, and to ease reverting if more problems crop up. The summary of D61940: This patch removes the "ChangingRegs" facility in DbgEntityHistoryCalculator, as its overapproximate nature can produce incorrect variable locations. An unchanging register doesn't mean a variable doesn't change its location. The patch kills off everything that calculates the ChangingRegs vector. Previously ChangingRegs spotted epilogues and marked registers as unchanging if they weren't modified outside the epilogue, increasing the chance that we can emit a single-location variable record. Without this feature, debug-loc-offset.mir and pr19307.mir become temporarily XFAIL. They'll be re-enabled by D62314, using the FrameDestroy flag to identify epilogues, I've split this into two steps as FrameDestroy isn't necessarily supported by all backends. The logic for terminating variable locations at the end of a basic block now becomes much more enjoyably simple: we just terminate them all. Other test changes: inlined-argument.ll becomes XFAIL, but for a longer term. The current algorithm for detecting that a variable has a single-location doesn't work in this scenario (inlined function in multiple blocks), only other bugs were making this test work. fission-ranges.ll gets slightly refreshed too, as the location of "p" is now correctly determined to be a single location. Differential Revision: https://reviews.llvm.org/D61940 llvm-svn: 362951
* [DebugInfo] More strict debug range for stack variablesNikola Prica2019-06-102-1/+185
| | | | | | | | | | | | | | | | | | | | | | | | | | | Variable's stack location can stretch longer than it should. If a variable is placed at the stack in a some nested basic block its range can be calculated to be up to the next occurrence of the variable's DBG_VALUE, or up to the end of the function, thus covering a basic blocks that should not be included in the variable’s location range. This happens because the DbgEntityHistoryCalculator ends register locations at the end of a basic block only if the variable’s location register has been changed throughout the function, which is not the case for the register used to reference stack objects. This patch also tries to produce a single value location if the location list builder managed to merge all the locations into one. Reviewers: aprantl, dstenb, jmorse Reviewed By: aprantl, dstenb, jmorse Subscribers: djtodoro, ivanbaev, asowda Tags: #debug-info Differential Revision: https://reviews.llvm.org/D61600 llvm-svn: 362923
* [DebugInfo] Incorrect debug info record generated for loop counter.Alexey Lapshin2019-06-062-5/+4
| | | | | | | | | | | | | 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
* [LiveDebugValues] Close range for previous variable's location when adding ↵Nikola Prica2019-06-031-9/+24
| | | | | | | | | | | | | | | | | | | | | | newly deduced location When LiveDebugValues deduces new variable's location from spill, restore or register copy instruction it should close old variable's location. Otherwise we can have multiple block output locations for same variable. That could lead to inserting two DBG_VALUEs for same variable to the beginning of the successor block which results to ignoring of first DBG_VALUE. Reviewers: aprantl, jmorse, wolfgangp, dstenb Reviewed By: aprantl Subscribers: probinson, asowda, ivanbaev, petarj, djtodoro Tags: #debug-info Differential Revision: https://reviews.llvm.org/D62196 llvm-svn: 362373
* [COFF, ARM64] Fix location of ARM64 CodeView testTom Tan2019-06-012-1/+4
| | | | | | | | ARM64 CodeView test was incorrectly put under test/DebugInfo/COFF folder which runs for all all architectures. This fix moves it to a subfolder AArch64 with lit.local.cfg which specify it supports AArch64 only. llvm-svn: 362283
* [COFF, ARM64] Add CodeView register mappingTom Tan2019-05-311-0/+149
| | | | | | | | | | | | | | | | CodeView has its own register map which is defined in cvconst.h. Missing this mapping before saving register to CodeView causes debugger to show incorrect value for all register based variables, like variables in register and local variables addressed by register (stack pointer + offset). This change added mapping between LLVM register and CodeView register so the correct register number will be stored to CodeView/PDB, it aso fixed the mapping from CodeView register number to register name based on current CPUType but print PDB to yaml still assumes X86 CPU and needs to be fixed. Differential Revision: https://reviews.llvm.org/D62608 llvm-svn: 362280
* Add enums as global variables in the IR metadata.Amy Huang2019-05-301-56/+92
| | | | | | | | | | | | | | | | Summary: Keeps track of the enums that were used by saving them as DIGlobalVariables, since CodeView emits debug info for global constants. Reviewers: rnk Subscribers: aprantl, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62635 llvm-svn: 362166
* CodeView - add static data members to global variable debug info.Amy Huang2019-05-291-26/+47
| | | | | | | | | | | | | | | | | | Summary: Add static data members to IR debug info's list of global variables so that they are emitted as S_CONSTANT records. Related to https://bugs.llvm.org/show_bug.cgi?id=41615. Reviewers: rnk Subscribers: aprantl, cfe-commits, llvm-commits, thakis Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62167 llvm-svn: 362038
* Stop undef fragments from closing non-overlapping fragmentsDavid Stenberg2019-05-282-0/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When DwarfDebug::buildLocationList() encountered an undef debug value, it would truncate all open values, regardless if they were overlapping or not. This patch fixes so that it only does that for overlapping fragments. This change unearthed a bug that I had introduced in D57511, which I have fixed in this patch. The code in DebugHandlerBase that changes labels for parameter debug values could break DwarfDebug's assumption that the labels for the entries in the debug value history are monotonically increasing. Before this patch, that bug could result in location list entries whose ending address was lower than the beginning address, and with the changes for undef debug values that this patch introduces it could trigger an assertion, due to attempting to emit location list entries with empty ranges. A reproducer for the bug is added in param-reg-const-mix.mir. Reviewers: aprantl, jmorse, probinson Reviewed By: aprantl Subscribers: javed.absar, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D62379 llvm-svn: 361820
* llvm-dwarfdump: Don't error on mixed units using/not using str_offsetsDavid Blaikie2019-05-257-228/+176
| | | | | | | | | | | This lead to errors when dumping binaries with v4 and v5 units linked together (but could've also errored on v5 units that did/didn't use str_offsets). Also improves error handling and messages around invalid str_offsets contributions. llvm-svn: 361683
* dwarfdump: Deterministically... determine whether parsing a DWARF32 or ↵David Blaikie2019-05-241-3/+4
| | | | | | | | | DWARF64 str_offsets header Rather than trying one and then the other - use the kind of the CU to select which kind of header to parse. llvm-svn: 361589
* dwarfdump: Add a bit more DWARF64 supportDavid Blaikie2019-05-241-3/+4
| | | | | | | | | | | | This test case was incorrect because it mixed DWARF32 and DWARF64 for a single unit (DWARF32 unit referencing a DWARF64 str_offsets section). So fix enough of the unit parsing for DWARF64 and make the test valid. (not sure if anyone needs DWARF64 support though - support in libDebugInfoDWARF has been added piecemeal and LLVM doesn't produce it at all) llvm-svn: 361582
* [DebugInfo] Fix tests missed by r362148Paul Robinson2019-05-211-5/+5
| | | | llvm-svn: 361251
* Revert r360902 "Resubmit: [Salvage] Change salvage debug info ..."Bob Haarman2019-05-211-25/+0
| | | | | | | | | | | This reverts commit rr360902. It caused an assertion failure in lib/IR/DebugInfoMetadata.cpp: Assertion `(OffsetInBits + SizeInBits <= FragmentSizeInBits) && "new fragment outside of original fragment"' failed. PR41931. llvm-svn: 361246
* [DebugInfo] Handle -main-file-name correctly for asm source.Paul Robinson2019-05-211-17/+0
| | | | | | | | | | This option provides only the base filename, not a full relative path. Part of the fix for PR41839. Differential Revision: https://reviews.llvm.org/D62071 llvm-svn: 361245
* Emit global variables as S_CONSTANT records for codeview debug info.Amy Huang2019-05-161-0/+64
| | | | | | | | | | | | | | | | | | | | Summary: This emits S_CONSTANT records for global variables. Currently this emits records for the global variables already being tracked in the LLVM IR metadata, which are just constant global variables; we'll also want S_CONSTANTs for static data members and enums. Related to https://bugs.llvm.org/show_bug.cgi?id=41615 Reviewers: rnk Subscribers: aprantl, hiraditya, llvm-commits, thakis Tags: #llvm Differential Revision: https://reviews.llvm.org/D61926 llvm-svn: 360948
* Resubmit: [Salvage] Change salvage debug info implementation to use ↵Stephen Tozer2019-05-161-0/+25
| | | | | | | | | | | | | | | | | | DW_OP_LLVM_convert where needed Fixes issue: https://bugs.llvm.org/show_bug.cgi?id=40645 Previously, LLVM had no functional way of performing casts inside of a DIExpression(), which made salvaging cast instructions other than Noop casts impossible. With the recent addition of DW_OP_LLVM_convert this salvaging is now possible, and so can be used to fix the attached bug as well as any cases where SExt instruction results are lost in the debugging metadata. This patch introduces this fix by expanding the salvage debug info method to cover these cases using the new operator. Differential revision: https://reviews.llvm.org/D61184 llvm-svn: 360902
* RegAllocFast: Improve hinting heuristicMatt Arsenault2019-05-162-36/+34
| | | | | | | | | | | | | | | Trace through multiple COPYs when looking for a physreg source. Add hinting for vregs that will be copied into physregs (we only hinted for vregs getting copied to a physreg previously). Give hinted a register a bonus when deciding which value to spill. This is part of my rewrite regallocfast series. In fact this one doesn't even have an effect unless you also flip the allocation to happen from back to front of a basic block. Nonetheless it helps to split this up to ease review of D52010 Patch by Matthias Braun llvm-svn: 360887
* [codeview] Finish support for reading and writing S_ANNOTATION recordsReid Kleckner2019-05-153-2/+90
| | | | | | Implement dumping via llvm-pdbutil and llvm-readobj. llvm-svn: 360813
* Revert "[Salvage] Change salvage debug info implementation to use ↵Stephen Tozer2019-05-151-25/+0
| | | | | | | | | DW_OP_LLVM_convert where needed" This reverts r360772 due to build issues. Reverted commit: 17dd4d7403770bd683675e45f5517e0cdb8f9b2b. llvm-svn: 360773
* [Salvage] Change salvage debug info implementation to use DW_OP_LLVM_convert ↵Stephen Tozer2019-05-151-0/+25
| | | | | | | | | | | | | | | | | | where needed Fixes issue: https://bugs.llvm.org/show_bug.cgi?id=40645 Previously, LLVM had no functional way of performing casts inside of a DIExpression(), which made salvaging cast instructions other than Noop casts impossible. With the recent addition of DW_OP_LLVM_convert this salvaging is now possible, and so can be used to fix the attached bug as well as any cases where SExt instruction results are lost in the debugging metadata. This patch introduces this fix by expanding the salvage debug info method to cover these cases using the new operator. Differential revision: https://reviews.llvm.org/D61184 llvm-svn: 360772
* [IR] Disallow llvm.global_ctors and llvm.global_dtors of the 2-field form in ↵Fangrui Song2019-05-157-8/+8
| | | | | | | | | | | | | | | | | | | | textual format The 3-field form was introduced by D3499 in 2014 and the legacy 2-field form was planned to be removed in LLVM 4.0 For the textual format, this patch migrates the existing 2-field form to use the 3-field form and deletes the compatibility code. test/Verifier/global-ctors-2.ll checks we have a friendly error message. For bitcode, lib/IR/AutoUpgrade UpgradeGlobalVariables will upgrade the 2-field form (add i8* null as the third field). Reviewed By: rnk, dexonsmith Differential Revision: https://reviews.llvm.org/D61547 llvm-svn: 360742
* DWARF v5: emit DW_AT_addr_base if DW_AT_low_pc references .debug_addrFangrui Song2019-05-143-1/+24
| | | | | | | | | | | | | | | | The condition !AddrPool.empty() is tested before attachRangesOrLowHighPC(), which may add an entry to AddrPool. We emit DW_AT_low_pc (DW_FORM_addrx) but may incorrectly omit DW_AT_addr_base for LineTablesOnly. This can be easily reproduced: clang -gdwarf-5 -gmlt -c a.cc Fix this by moving !AddrPool.empty() below. This was discovered while investigating an lld crash (fixed by D61889) on such object files: ld.lld --gdb-index a.o Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D61891 llvm-svn: 360678
OpenPOWER on IntegriCloud