summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/X86
Commit message (Collapse)AuthorAgeFilesLines
...
* [DebugInfo] Use FrameDestroy to extend stack locations to end-of-functionJeremy Morse2019-06-133-17/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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-105-10/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Stop undef fragments from closing non-overlapping fragmentsDavid Stenberg2019-05-281-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* 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
* [IR] Disallow llvm.global_ctors and llvm.global_dtors of the 2-field form in ↵Fangrui Song2019-05-154-4/+4
| | | | | | | | | | | | | | | | | | | | 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-142-1/+3
| | | | | | | | | | | | | | | | 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
* DebugInfo: Only move types out of type units if they're named or type unitedDavid Blaikie2019-05-101-0/+79
| | | | | | | | | | | | | | | | | | Follow up to r359122, after a bug was reported in it - the original change too aggressively tried to move related types out of type units, which included unnamed types (like array types) which can't reasonably be declared-but-not-defined. A step beyond that is that some types in type units can be anonymous, if they are types with a name for linkage purposes (eg: "typedef struct { } x;"). So ensure those don't get turned into plain declarations (without signatures) because, lacking names, they can't be resolved to the definition. [Also include a fix for llvm-dwarfdump/libDebugInfoDWARF to pretty print types in type units] llvm-svn: 360458
* [DebugInfo] Use zero linenos for debug intrinsics when promoting dbg.declareJeremy Morse2019-05-101-0/+3
| | | | | | | | | | | | | | | | | | | | In certain circumstances, optimizations pick line numbers from debug intrinsic instructions as the new location for altered instructions. This is problematic because the line number of a debugging intrinsic is meaningless (it doesn't produce any machine instruction), only the scope information is valid. The result can be the line number of a variable declaration "leaking" into real code from debugging intrinsics, making the line table un-necessarily jumpy, and potentially different with / without variable locations. Fix this by using zero line numbers when promoting dbg.declare intrinsics into dbg.values: this is safe for debug intrinsics as their line numbers are meaningless, and reduces the scope for damage / misleading stepping when optimizations pick locations from the wrong place. Differential Revision: https://reviews.llvm.org/D59272 llvm-svn: 360415
* Temporarily Revert "[DebugInfo] Terminate more location-list ranges at the ↵Eric Christopher2019-05-082-362/+7
| | | | | | | | | | end of blocks" as it was causing significant compile time regressions. This reverts commit r359426 while we come up with testcases and additional ideas. llvm-svn: 360301
* [llvm-objdump] - Print relocation record in a GNU format.George Rimar2019-05-072-2/+2
| | | | | | | | | | | | | | | This fixes the https://bugs.llvm.org/show_bug.cgi?id=41355. Previously with -r we printed relocation section name instead of the target section name. It was like this: "RELOCATION RECORDS FOR [.rel.text]" Now it is: "RELOCATION RECORDS FOR [.text]" Also when relocation target section has more than one relocation section, we did not combine the output. Now we do. Differential revision: https://reviews.llvm.org/D61312 llvm-svn: 360143
* Reapply r359906, "RegAllocFast: Add heuristic to detect values not live-out ↵Matt Arsenault2019-05-031-1/+0
| | | | | | | | | | | of a block" This reverts commit r359912. This should pass now, since the clang test was made less fragile in r359918. llvm-svn: 359919
* Revert r359906, "RegAllocFast: Add heuristic to detect values not live-out ↵Nico Weber2019-05-031-0/+1
| | | | | | | | of a block" Makes clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp fail. llvm-svn: 359912
* RegAllocFast: Add heuristic to detect values not live-out of a blockMatt Arsenault2019-05-031-1/+0
| | | | | | | | | Add an improved/new heuristic to catch more cases when values are not live out of a basic block. Patch by Matthias Braun llvm-svn: 359906
* [llvm-readobj] Change -t to --symbols in tests. NFCFangrui Song2019-05-011-2/+2
| | | | | | | | | | -t is --symbols in llvm-readobj but --section-details (unimplemented) in readelf. The confusing option should not be used since we aim for improving compatibility. Keep just one llvm-readobj -t use case in test/tools/llvm-readobj/symbols.test llvm-svn: 359661
* [llvm-readobj] Change -long-option to --long-option in tests. NFCFangrui Song2019-05-015-21/+21
| | | | | | | | | | We use both -long-option and --long-option in tests. Switch to --long-option for consistency. In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf. While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf). llvm-svn: 359649
* [CommandLine] Don't allow unlimitted dashes for options. Part 1 or 5Don Hinton2019-04-291-1/+1
| | | | | | | | | | | | | | | | | | | Summary: Prior to this patch, the CommandLine parser would strip an unlimitted number of dashes from options. This patch limits it to two. Reviewers: rnk Reviewed By: rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61229 llvm-svn: 359480
* [DebugInfo] Terminate more location-list ranges at the end of blocksJeremy Morse2019-04-292-7/+362
| | | | | | | | | | | | | | | | This patch fixes PR40795, where constant-valued variable locations can "leak" into blocks placed at higher addresses. The root of this is that DbgEntityHistoryCalculator terminates all register variable locations at the end of each block, but not constant-value variable locations. Fixing this requires constant-valued DBG_VALUE instructions to be broadcast into all blocks where the variable location remains valid, as documented in the LiveDebugValues section of SourceLevelDebugging.rst, and correct termination in DbgEntityHistoryCalculator. Differential Revision: https://reviews.llvm.org/D59431 llvm-svn: 359426
* [llvm-nm][llvm-readelf] Avoid single-dash -long-option in testsFangrui Song2019-04-271-1/+1
| | | | llvm-svn: 359383
* DebugInfo: Emit only declarations (not whole definitions) of non-unit user ↵David Blaikie2019-04-241-0/+63
| | | | | | | | | | | | | | | | | | | | defined types into type units While this doesn't come up in reasonable cases currently (the only user defined types not in type units are ones without linkage - which makes for near-ODR violations, because it'd be a type with linkage referencing a type without linkage - such a type can't be validly defined in more than one TU, so arguably it shouldn't be in a type unit to begin with - but it's a convenient way to demonstrate an issue that will become more revalent with homed modular debug info type definitions - which also don't need to be in type units but more legitimately so). Precursor to the Clang change to de-type-unit (by omitting the 'identifier') types homed due to strong linkage vtables. (making that change without this one would lead to major type duplication in type units) llvm-svn: 359122
* Reapply: "DebugInfo: Emit only one kind of accelerated access/name table""David Blaikie2019-04-232-2/+90
| | | | | | | | | | | | | | | | | | | | | | | | | Originally committed in r358931 Reverted in r358997 Seems this change made Apple accelerator tables miss names (because names started respecting the CU NameTableKind GNU & assuming that shouldn't produce accelerated names too), which is never correct (apple accelerator tables don't have separators or CU lists - if present, they must describe all names in all CUs). Original Description: Currently to opt in to debug_names in DWARFv5, the IR must contain 'nameTableKind: Default' which also enables debug_pubnames. Instead, only allow one of {debug_names, apple_names, debug_pubnames, debug_gnu_pubnames}. nameTableKind: Default gives debug_names in DWARFv5 and greater, debug_pubnames in v4 and earlier - and apple_names when tuning for lldb on MachO. nameTableKind: GNU always gives gnu_pubnames llvm-svn: 359026
* Revert "DebugInfo: Emit only one kind of accelerated access/name table"David Blaikie2019-04-232-86/+2
| | | | | | | | Regresses some apple_names situations - still investigating. This reverts commit r358931. llvm-svn: 358997
* DebugInfo: Emit only one kind of accelerated access/name tableDavid Blaikie2019-04-222-2/+86
| | | | | | | | | | | | | | | Currently to opt in to debug_names in DWARFv5, the IR must contain 'nameTableKind: Default' which also enables debug_pubnames. Instead, only allow one of {debug_names, apple_names, debug_pubnames, debug_gnu_pubnames}. nameTableKind: Default gives debug_names in DWARFv5 and greater, debug_pubnames in v4 and earlier - and apple_names when tuning for lldb on MachO. nameTableKind: GNU always gives gnu_pubnames llvm-svn: 358931
* [DebugInfo] Combine Trivial and NonTrivial flagsAaron Smith2019-04-113-4/+4
| | | | | | | | | | | | | | | | Summary: Companion to https://reviews.llvm.org/D59347 Reviewers: rnk, zturner, probinson, dblaikie, deadalnix Subscribers: aprantl, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59348 llvm-svn: 358220
* [DebugInfo] Improve handling of clobbered fragmentsDavid Stenberg2019-04-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [X86] Merge the different Jcc instructions for each condition code into ↵Craig Topper2019-04-053-10/+10
| | | | | | | | | | | | | | | | | | | | | single instructions that store the condition code as an operand. Summary: This avoids needing an isel pattern for each condition code. And it removes translation switches for converting between Jcc instructions and condition codes. Now the printer, encoder and disassembler take care of converting the immediate. We use InstAliases to handle the assembly matching. But we print using the asm string in the instruction definition. The instruction itself is marked IsCodeGenOnly=1 to hide it from the assembly parser. Reviewers: spatel, lebedev.ri, courbet, gchatelet, RKSimon Reviewed By: RKSimon Subscribers: MatzeB, qcolombet, eraman, hiraditya, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60228 llvm-svn: 357802
* RegAllocFast: Remove early selection loop, the spill calculation will report ↵Matt Arsenault2019-03-191-4/+4
| | | | | | | | | | | | | | | | cost 0 anyway for free regs The 2nd loop calculates spill costs but reports free registers as cost 0 anyway, so there is little benefit from having a separate early loop. Surprisingly this is not NFC, as many register are marked regDisabled so the first loop often picks up later registers unnecessarily instead of the first one available in the allocation order... Patch by Matthias Braun llvm-svn: 356499
* [DebugInfo] Move test files added in r356451Markus Lavin2019-03-193-0/+323
| | | | | | | Moved the X86 dependant .ll tests added in r356451 from test/DebugInfo/Generic to test/DebugInfo/X86. llvm-svn: 356460
* [DebugInfoMetadata] Move main subprogram DIFlag into DISPFlagsPetar Jovanovic2019-03-191-1/+1
| | | | | | | | | | | | Moving subprogram specific flags into DISPFlags makes IR code more readable. In addition, we provide free space in DIFlags for other 'non-subprogram-specific' debug info flags. Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D59288 llvm-svn: 356454
* [DebugInfo] Construct nested types on behalf of owner CUEugene Leviant2019-03-041-0/+98
| | | | | | Differential revision: https://reviews.llvm.org/D58786 llvm-svn: 355303
* [DebugInfo] Apply subprogram attributes on behalf of owner CUEugene Leviant2019-02-271-0/+92
| | | | | | | | | | | | When using full LTO it is possible that template function definition DIE is bound to one compilation unit and it's declaration to another. We should add function declaration attributes on behalf of its owner CU otherwise we may end up with malformed file identifier in function declaration DW_AT_decl_file attribute. Differential revision: https://reviews.llvm.org/D58538 llvm-svn: 354978
* [DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEsJeremy Morse2019-02-132-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | In this patch SelectionDAG tries to salvage any dbg.values that are going to be dropped, in case they can be recovered from Values in the current BB. It also strengthens SelectionDAGs handling of dangling debug data, so that dbg.values are *always* emitted (as Undef or otherwise) instead of dangling forever. The motivation behind this patch exists in the new test case: a memory address (here a bitcast and GEP) exist in one basic block, and a dbg.value referring to the address is left in the 'next' block. The base pointer is live across all basic blocks. In current llvm trunk the dbg.value cannot be encoded, and it isn't even emitted as an Undef DBG_VALUE. The change is simply: if we're definitely going to drop a dbg.value, repeatedly apply salvageDebugInfo to its operand until either we find something that can be encoded, or we can't salvage any further in which case we produce an Undef DBG_VALUE. To know when we're "definitely going to drop a dbg.value", SelectionDAG signals SelectionDAGBuilder when all IR instructions have been encoded to force salvaging. This ensures that any dbg.value that's dangling after DAG creation will have a corresponding DBG_VALUE encoded. Differential Revision: https://reviews.llvm.org/D57694 llvm-svn: 353954
* [DebugInfo][DAG] Limit special-casing of dbg.values for ArgumentsJeremy Morse2019-02-131-0/+104
| | | | | | | | | | | | | | | | | | | | | SelectionDAGBuilder has special handling for dbg.value intrinsics that are understood to define the location of function parameters on entry to the function. To enable this, we avoid recording a dbg.value as a virtual register reference if it might be such a parameter, so that it later hits EmitFuncArgumentDbgValue. This patch reduces the set of circumstances where we avoid recording a dbg.value as a virtual register reference, to allow more "normal" variables to be recorded that way. We now only bypass for potential parameters if: * The dbg.value operand is an Argument, * The Variable is a parameter, and * The Variable is not inlined. meaning it's very likely that the dbg.value is a function-entry parameter location. Differential Revision: https://reviews.llvm.org/D57584 llvm-svn: 353948
* [DebugInfo] Stop changing labels for register-described parameter DBG_VALUEsDavid Stenberg2019-02-133-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to D57510. This patch stops DebugHandlerBase from changing the starting label for the first non-overlapping, register-described parameter DBG_VALUEs to the beginning of the function. That code did not consider what defined the registers, which could result in the ranges for the debug values starting before their defining instructions. We currently do not emit debug values for constant values directly at the start of the function, so this code is still useful for such values, but my intention is to remove the code from DebugHandlerBase completely when we get there. One reason for removing it is that the code violates the history map's ranges, which I think can make it quite confusing when troubleshooting. In D57510, PrologEpilogInserter was amended so that parameter DBG_VALUEs now are kept at the start of the entry block, even after emission of prologue code. That was done to reduce the degradation of debug completeness from this patch. PR40638 is another example, where the lexical-scope trimming that LDV does, in combination with scheduling, results in instructions after the prologue being left without locations. There might be other cases where the DBG_VALUEs are pushed further down, for which the DebugHandlerBase code may be helpful, but as it now quite often result in incorrect locations, even after the prologue, it seems better to remove that code, and try to work our way up with accurate locations. In the long run we should maybe not aim to provide accurate locations inside the prologue. Some single location descriptions, at least those referring to stack values, generate inaccurate values inside the epilogue, so we maybe should not aim to achieve accuracy for location lists. However, it seems that we now emit line number programs that can result in GDB and LLDB stopping inside the prologue when doing line number stepping into functions. See PR40188 for more information. A summary of some of the changed test cases is available in PR40188#c2. Reviewers: aprantl, dblaikie, rnk, jmorse Reviewed By: aprantl Subscribers: jdoerfert, jholewinski, jvesely, javed.absar, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D57511 llvm-svn: 353928
* [DebugInfo] Keep parameter DBG_VALUEs before prologue codeDavid Stenberg2019-02-121-0/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a preparatory change for removing the code from DebugHandlerBase::beginFunction() which changes the starting label for the first non-overlapping DBG_VALUEs of parameters to the beginning of the function. It does that to be able to show parameters when entering a function. However, that code does not consider what defines the values, which can result in the ranges for the debug values starting before their defining instructions. That code is removed in a follow-up patch. When prologue code is inserted, it leads to DBG_VALUEs that start directly in the entry block being moved down after the prologue instructions. This patch fixes that by stashing away DBG_VALUEs for parameters before emitting the prologue, and then reinserts them at the start of the block. This assumes that there is no target that somehow clobbers parameter registers in the frame setup; there is no such case in the lit tests at least. See PR40188 for more information. Reviewers: aprantl, dblaikie, rnk, jmorse Reviewed By: aprantl Subscribers: bjope, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D57510 llvm-svn: 353823
* Fix r353771 to target linux only (split-dwarf isn't supported on macho)David Blaikie2019-02-121-0/+2
| | | | llvm-svn: 353785
* DebugInfo: Split DWARF + gmlt + no-split-dwarf-inlining shouldn't emit ↵David Blaikie2019-02-121-0/+28
| | | | | | | | | | | | | | | anything to the .dwo file This configuration (due to r349207) was intended not to emit any DWO CU, but a degenerate CU was still being emitted - containing a header and a DW_TAG_compile_unit with no attributes. Under that situation, emit nothing to the .dwo file. (since this is a dynamic property of the input the .dwo file is still emitted, just with nothing in it (so a valid, but empty, ELF file) - if some other CU didn't satisfy this criteria, its DWO CU would still go there, etc) llvm-svn: 353771
* [SelectionDAGBuilder] Add restrictions to EmitFuncArgumentDbgValueBjorn Pettersson2019-02-112-0/+293
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes PR40587. When a dbg.value instrinsic is emitted to the DAG by using EmitFuncArgumentDbgValue the resulting DBG_VALUE is hoisted to the beginning of the entry block. I think the idea is to be able to locate a formal argument already from the start of the function. However, EmitFuncArgumentDbgValue only checked that the value that was used to describe a variable was originating from a function parameter, not that the variable itself actually was an argument to the function. So when for example assigning a local variable "local" the value from an argument "a", the assocated DBG_VALUE instruction would be hoisted to the beginning of the function, even if the scope for "local" started somewhere else (or if "local" was mapped to other values earlier in the function). This patch adds some logic to EmitFuncArgumentDbgValue to check that the variable being described actually is an argument to the function. And that the dbg.value being lowered already is in the entry block. Otherwise we bail out, and the dbg.value will be handled as an ordinary dbg.value (not as a "FuncArgumentDbgValue"). A tricky situation is when both the variable and the value is related to function arguments, but not neccessarily the same argument. We make sure that we do not describe the same argument more than once as a "FuncArgumentDbgValue". This solution works as long as opt has injected a "first" dbg.value that corresponds to the formal argument at the function entry. Reviewers: jmorse, aprantl Subscribers: jyknight, hiraditya, fedor.sergeev, dstenb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57702 llvm-svn: 353735
* [DWARF v5] Fix DWARF emitter and consumer to produce/expect a uleb for a ↵Wolfgang Pieb2019-02-011-4/+4
| | | | | | | | | | location description's length. Reviewer: davide, JDevliegere Differential Revision: https://reviews.llvm.org/D57550 llvm-svn: 352889
* [DebugInfo][DAG] Process FrameIndex dbg.values unconditionallyJeremy Morse2019-01-291-0/+79
| | | | | | | | | | | | | | | A FrameIndex should be valid throughout a block regardless of what instructions get selected in that block -- therefore we shouldn't harness dbg.values that refer to FrameIndexes to an SDNode. There are numerous codegen reasons why an SDNode never appears or doesn't become a location that a DBG_VALUE can refer to. None of them actually affect the variable location. Therefore, before any other tests to encode dbg_values in a SelectionDAG, identify FrameIndex operands and encode them unattached to any SDNode. Differential Revision: https://reviews.llvm.org/D57328 llvm-svn: 352467
* Fix an incorrectly configured test.Jeremy Morse2019-01-291-0/+2
| | | | | | This should have had a target triple in it, my mistake. llvm-svn: 352460
OpenPOWER on IntegriCloud