summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/X86
Commit message (Collapse)AuthorAgeFilesLines
* [MC] Report fatal error for DWARF types for non-ELF object filesJonas Devlieghere2018-08-012-4/+10
| | | | | | | | | | | | | | Getting the DWARF types section is only implemented for ELF object files. We already disabled emitting debug types in clang (r337717), but now we also report an fatal error (rather than crashing) when trying to obtain this section in MC. Additionally we ignore the generate debug types flag for unsupported target triples. See PR38190 for more information. Differential revision: https://reviews.llvm.org/D50057 llvm-svn: 338527
* [DWARF] Basic support for producing DWARFv5 .debug_addr sectionVictor Leschuk2018-08-011-0/+79
| | | | | | | | | | | | | | This revision implements support for generating DWARFv5 .debug_addr section. The implementation is pretty straight-forward: we just check the dwarf version and emit section header if needed. Reviewers: aprantl, dblaikie, probinson Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D50005 llvm-svn: 338487
* [DWARF v5] Reposting r337981, which was reverted in r337997 due to a test ↵Wolfgang Pieb2018-07-263-0/+150
| | | | | | | | | failure in debuginfo_tests. The test failure was caused by the compiler not emitting a __debug_ranges section with DWARF 4 and earlier when no ranges are needed. The test checks for the existence regardless. llvm-svn: 338081
* [DebugInfo] LowerDbgDeclare: Add derefs when handling CallInst usersVedant Kumar2018-07-264-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LowerDbgDeclare inserts a dbg.value before each use of an address described by a dbg.declare. When inserting a dbg.value before a CallInst use, however, it fails to append DW_OP_deref to the DIExpression. The DW_OP_deref is needed to reflect the fact that a dbg.value describes a source variable directly (as opposed to a dbg.declare, which relies on pointer indirection). This patch adds in the DW_OP_deref where needed. This results in the correct values being shown during a debug session for a program compiled with ASan and optimizations (see https://reviews.llvm.org/D49520). Note that ConvertDebugDeclareToDebugValue is already correct -- no changes there were needed. One complication is that SelectionDAG is unable to distinguish between direct and indirect frame-index (FRAMEIX) SDDbgValues. This patch also fixes this long-standing issue in order to not regress integration tests relying on the incorrect assumption that all frame-index SDDbgValues are indirect. This is a necessary fix: the newly-added DW_OP_derefs cannot be lowered properly otherwise. Basically the fix prevents a direct SDDbgValue with DIExpression(DW_OP_deref) from being dereferenced twice by a debugger. There were a handful of tests relying on this incorrect "FRAMEIX => indirect" assumption which actually had incorrect DW_AT_locations: these are all fixed up in this patch. Testing: - check-llvm, and an end-to-end test using lldb to debug an optimized program. - Existing unit tests for DIExpression::appendToStack fully cover the new DIExpression::append utility. - check-debuginfo (the debug info integration tests) Differential Revision: https://reviews.llvm.org/D49454 llvm-svn: 338069
* Revert r337981: it breaks the debuginfo-testsAlex Lorenz2018-07-263-150/+0
| | | | | | | This commit caused a regression in the debuginfo-tests: FAIL: debuginfo-tests :: apple-accel.cpp (40748 of 46595) llvm-svn: 337997
* [DWARF v5] Don't report an error when the .debug_rnglists section is empty ↵Wolfgang Pieb2018-07-261-1/+6
| | | | | | | | | | | or non-existent. Fixes PR38297. Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D49815 llvm-svn: 337993
* [DWARF v5] Don't emit multiple DW_AT_rnglists_base attributes. Some ↵Wolfgang Pieb2018-07-253-0/+150
| | | | | | | | | | | | refactoring of range lists emissions and added test cases. Reviewer: dblaikie Differential Revision: https://reviews.llvm.org/D49522 llvm-svn: 337981
* [DWARF v5] Refactor range lists dumping by using a more generic way of ↵Wolfgang Pieb2018-07-231-2/+2
| | | | | | | | | | | | | handling tables of lists. The intent is to use it for location list tables as well. Change is almost NFC with the exception of the spelling of some strings used during dumping (all lowercase now). Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D49500 llvm-svn: 337763
* [DebugInfo] Generate .debug_names section when it makes sensePavel Labath2018-07-203-10/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes us generate the debug_names section in response to some user-facing commands (previously it was only generated if explicitly selected via the -accel-tables option). My goal was to make this work for DWARF>=5 (as it's an official part of that standard), and also, as an extension, for DWARF<5 if one is explicitly tuning for lldb as a debugger (because it brings a large performance improvement there). This is slightly complicated by the fact that the debug_names tables are incompatible with the DWARF v4 type units (they assume that the type units are in the debug_info section), and unfortunately, right now we generate DWARF v4-style type units even for -gdwarf-5. For this reason, I disable all accelerator tables if the user requested type unit generation. I do this even for apple tables, as they have the same problem (in fact generating type units for apple targets makes us crash even before we get around to emitting the accelerator tables). Reviewers: JDevlieghere, aprantl, dblaikie, echristo, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49420 llvm-svn: 337544
* Rename __asan_gen_* symbols to ___asan_gen_*.Peter Collingbourne2018-07-182-4/+4
| | | | | | | | | | This prevents gold from printing a warning when trying to export these symbols via the asan dynamic list after ThinLTO promotes them from private symbols to external symbols with hidden visibility. Differential Revision: https://reviews.llvm.org/D49498 llvm-svn: 337428
* Fix some tests that had (implied) duplicate mtripleDavid Blaikie2018-07-182-6/+6
| | | | | | | I 'fixed' one of these to use %llc_dwarf unnecessarily, so switch them both back to using llc directly. llvm-svn: 337423
* [DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglistsDavid Blaikie2018-07-183-92/+85
| | | | | | | | | | | | Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
* [dwarfdump] Pretty print DW_AT_APPLE_runtime_classJonas Devlieghere2018-07-131-0/+1
| | | | | | | | | | | | Instead of printing DW_AT_APPLE_runtime_class (0x10) we now print DW_AT_APPLE_runtime_class (DW_LANG_ObjC) llvm-svn: 337011
* [DWARF v5] Generate range list tables into the .debug_rnglists section. No ↵Wolfgang Pieb2018-07-122-2/+106
| | | | | | | | | | | | support for split DWARF and no use of DW_FORM_rnglistx with the DW_AT_ranges attribute. Reviewer: aprantl Differential Revision: https://reviews.llvm.org/D49214 llvm-svn: 336927
* NFC - Various typo fixes in testsGabor Buella2018-07-041-2/+2
| | | | llvm-svn: 336268
* [DebugInfo] Make sure all DBG_VALUEs' reguse operands have IsDebug propertyMikael Holmen2018-06-212-6/+6
| | | | | | | | | | | | | | | | | | | | | | 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
* [DebugInfo] Keep DBG_VALUE undef in LiveDebugVariablesMikael Holmen2018-06-212-9/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [DWARF] Improved error reporting for range lists. Wolfgang Pieb2018-06-202-3/+55
| | | | | | | | | | | Errors found processing the DW_AT_ranges attribute are propagated by lower level routines and reported by their callers. Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D48344 llvm-svn: 335188
* Re-apply "[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue"Bjorn Pettersson2018-06-151-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is r334704 (which was reverted in r334732) with a fix for types like x86_fp80. We need to use getTypeAllocSizeInBits and not getTypeStoreSizeInBits to avoid dropping debug info for such types. Original commit msg: > Summary: > Do not convert a DbgDeclare to DbgValue if the store > instruction only refer to a fragment of the variable > described by the DbgDeclare. > > Problem was seen when for example having an alloca for an > array or struct, and there were stores to individual elements. > In the past we inserted a DbgValue intrinsics for each store, > just as if the store wrote the whole variable. > > When handling store instructions we insert a DbgValue that > indicates that the variable is "undefined", as we do not know > which part of the variable that is updated by the store. > > When ConvertDebugDeclareToDebugValue is used with a load/phi > instruction we assert that the referenced value is large enough > to cover the whole variable. Afaict this should be true for all > scenarios where those methods are used on trunk. If the assert > blows in the future I guess we could simply skip to insert a > dbg.value instruction. > > In the future I think we should examine which part of the variable > that is accessed, and add a DbgValue instrinsic with an appropriate > DW_OP_LLVM_fragment expression. > > Reviewers: dblaikie, aprantl, rnk > > Reviewed By: aprantl > > Subscribers: JDevlieghere, llvm-commits > > Tags: #debug-info > > Differential Revision: https://reviews.llvm.org/D48024 llvm-svn: 334830
* Remove the test from r333801Vedant Kumar2018-06-021-21/+0
| | | | | | | | | | | | In r333801 I added a test for a dump method that, for reasons I don't understand, fails on an msvc bot: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/12306/ I'll remove the test for now to unblock the bot and try to look into why there's a discrepancy on this platform later. llvm-svn: 333807
* Add a debug dump for DbgValueHistoryMapVedant Kumar2018-06-011-0/+21
| | | | | | | | | This makes it easier to inspect the results of DbgValueHistoryCalculator. Differential Revision: https://reviews.llvm.org/D47663 llvm-svn: 333801
* Implemented sane default for llvm-objdump's relocation Value formatDaniel Cederman2018-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: "Unknown" for platforms that were not manually added into the switch did not make sense at all. Now it prints Target + addend for all elf-machines that were not explicitly mentioned. Addresses PR21059 and PR25124. Original author: fedor.sergeev Reviewers: jyknight, espindola, fedor.sergeev Reviewed By: jyknight Subscribers: eraman, dcederman, jfb, dschuff, aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D36464 llvm-svn: 333726
* [CodeView] Add prefix to CodeView registers.Jonas Devlieghere2018-05-291-3/+3
| | | | | | | | | | | | | Adds CVReg to CodeView register names to prevent a duplicate symbol with CR3 defined in termios.h, as suggested by Zachary on the mailing list. http://lists.llvm.org/pipermail/llvm-dev/2018-May/123372.html Differential revision: https://reviews.llvm.org/D47478 rdar://39863705 llvm-svn: 333421
* [DebugInfo] Maintain DI when converting GEP to bitcastVedant Kumar2018-05-241-0/+12
| | | | | | | | | | | When a GEP with all zero indices is converted to bitcast, its DI wasn't copied over to the newly created instruction. This patch fixes that bug. Patch by Kareem Ergawy! Differential Revision: https://reviews.llvm.org/D47347 llvm-svn: 333235
* Move a debug info test into the X86 directoryVedant Kumar2018-05-231-0/+36
| | | | | | | | | | | This test triggers a code path which does not appear to fire on some targets: http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/3028 I've made the test X86-specific in an attempt to address the issue. llvm-svn: 333138
* [DWARFv5] Put the DWO ID in its place.Paul Robinson2018-05-221-2/+3
| | | | | | | | | | | | In DWARF v5, the DWO ID is in the (split/skeleton) CU header, not an attribute on the CU DIE. This changes the size of those headers, so use the parsed size whenever we have one, for simplicitly. Differential Revision: https://reviews.llvm.org/D47158 llvm-svn: 333004
* [DebugInfo] Fix typo "DWARG" in test comment (NFC)Brian Gesiak2018-05-211-1/+1
| | | | | | | | | | | Summary: The correct spelling is "DWARF", the debugging format, not "DWARG". The typo is in a (not executed by lit) comment in a test file, so fixing it does not result in any functional change. Test Plan: check-llvm, just in case llvm-svn: 332878
* [DebugInfo] Use absolute addresses in location listsJonas Devlieghere2018-05-211-2/+2
| | | | | | | | | | | Rather than relying on the user to do the address calculating in DW_AT_location we should just dump the absolute address. rdar://problem/38513870 Differential revision: https://reviews.llvm.org/D47152 llvm-svn: 332873
* [DWARF v5] Improved support for .debug_rnglists (consumer). Enables any ↵Wolfgang Pieb2018-05-181-0/+192
| | | | | | | | | | | | consumer to extract DWARF v5 encoded rangelists. Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D45549 llvm-svn: 332759
* [DWARF] Fixing a bug in DWARF v5 string offsets tables where the length ↵Wolfgang Pieb2018-05-107-23/+23
| | | | | | | | | | | | | encoded the contribution length excluding the table header. Instead it must encode the contribution length minus the length field itself. Reviewer: JDevliegehere Differential Revision: https://reviews.llvm.org/D45922 llvm-svn: 332030
* [DWARF] Rework debug line parsing to use llvm::Error and callbacksJames Henderson2018-05-101-97/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reviewed by: dblaikie, JDevlieghere, espindola Differential Revision: https://reviews.llvm.org/D44560 Summary: The .debug_line parser previously reported errors by printing to stderr and return false. This is not particularly helpful for clients of the library code, as it prevents them from handling the errors in a manner based on the calling context. This change switches to using llvm::Error and callbacks to indicate what problems were detected during parsing, and has updated clients to handle the errors in a location-specific manner. In general, this means that they continue to do the same thing to external users. Below, I have outlined what the known behaviour changes are, relating to this change. There are two levels of "errors" in the new error mechanism, to broadly distinguish between different fail states of the parser, since not every failure will prevent parsing of the unit, or of subsequent unit. Malformed table errors that prevent reading the remainder of the table (reported by returning them) and other minor issues representing problems with parsing that do not prevent attempting to continue reading the table (reported by calling a specified callback funciton). The only example of this currently is when the last sequence of a unit is unterminated. However, I think it would be good to change the handling of unrecognised opcodes to report as minor issues as well, rather than just printing to the stream if --verbose is used (this would be a subsequent change however). I have substantially extended the DwarfGenerator to be able to handle custom-crafted .debug_line sections, allowing for comprehensive unit-testing of the parser code. For now, I am just adding unit tests to cover the basic error reporting, and positive cases, and do not currently intend to test every part of the parser, although the framework should be sufficient to do so at a later point. Known behaviour changes: - The dump function in DWARFContext now does not attempt to read subsequent tables when searching for a specific offset, if the unit length field of a table before the specified offset is a reserved value. - getOrParseLineTable now returns a useful Error if an invalid offset is encountered, rather than simply a nullptr. - The parse functions no longer use `WithColor::warning` directly to report errors, allowing LLD to call its own warning function. - The existing parse error messages have been updated to not specifically include "warning" in their message, allowing consumers to determine what severity the problem is. - If the line table version field appears to have a value less than 2, an informative error is returned, instead of just false. - If the line table unit length field uses a reserved value, an informative error is returned, instead of just false. - Dumping of .debug_line.dwo sections is now implemented the same as regular .debug_line sections. - Verbose dumping of .debug_line[.dwo] sections now prints the prologue, if there is a prologue error, just like non-verbose dumping. As a helper for the generator code, I have re-added emitInt64 to the AsmPrinter code. This previously existed, but was removed way back in r100296, presumably because it was dead at the time. This change also requires a change to LLD, which will be committed separately. llvm-svn: 331971
* [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.Shiva Chen2018-05-09180-299/+299
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
* DwarfCompileUnit: Fix another assertion failure on malformed inputAdrian Prantl2018-05-041-1/+2
| | | | | | | | that is not rejected by the Verifier. Thanks to Björn Pettersson for providing a reproducer! llvm-svn: 331535
* Reapply "[SelectionDAG] Selection of DBG_VALUE using a PHI node result (pt 2)"Bjorn Pettersson2018-05-032-0/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This reverts SVN r331441 (reapplies r331337), together with a fix in to handle an already existing fragment expression in the dbg.value that must be fragmented due to a split PHI node. This should solve the problem seen in PR37321, which was the reason for the revert of r331337. The situation in PR37321 is that we have a PHI node like this %u.sroa = phi i80 [ %u.sroa.x, %if.x ], [ %u.sroa.y, %if.y ], [ %u.sroa.z, %if.z ] and a dbg.value like this call void @llvm.dbg.value(metadata i80 %u.sroa, metadata !13, metadata !DIExpression(DW_OP_LLVM_fragment, 0, 80)) The phi node is split into three 32-bit PHI nodes %30:gr32 = PHI %11:gr32, %bb.4, %14:gr32, %bb.5, %27:gr32, %bb.8 %31:gr32 = PHI %12:gr32, %bb.4, %15:gr32, %bb.5, %28:gr32, %bb.8 %32:gr32 = PHI %13:gr32, %bb.4, %16:gr32, %bb.5, %29:gr32, %bb.8 but since the original value only is 80 bits we need to adjust the size of the last fragment expression, and with this patch we get DBG_VALUE debug-use %30:gr32, debug-use $noreg, !"u", !DIExpression(DW_OP_LLVM_fragment, 0, 32) DBG_VALUE debug-use %31:gr32, debug-use $noreg, !"u", !DIExpression(DW_OP_LLVM_fragment, 32, 32) DBG_VALUE debug-use %32:gr32, debug-use $noreg, !"u", !DIExpression(DW_OP_LLVM_fragment, 64, 16) Reviewers: vsk, aprantl, mstorsjo Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46384 llvm-svn: 331464
* Revert "[SelectionDAG] Selection of DBG_VALUE using a PHI node result (pt 2)"Martin Storsjo2018-05-031-169/+0
| | | | | | | This reverts SVN r331337, see PR37321 for details on the regression it introduced. llvm-svn: 331441
* [SelectionDAG] Selection of DBG_VALUE using a PHI node result (pt 2)Bjorn Pettersson2018-05-021-0/+169
| | | | | | | | | | | | | | | | | | | | | Summary: This is a follow up to rL331182. A PHI node can be split up into several MIR PHI nodes when being selected. When there is a dbg.value intrinsic that uses the result of such a PHI node we need to select several DBG_VALUE instructions, with fragment expressions, in order to do a correct selection. Reviewers: rnk, aprantl, vsk Reviewed By: vsk Subscribers: mattd, llvm-commits, JDevlieghere, aprantl, gbedwell, rnk Tags: #debug-info Differential Revision: https://reviews.llvm.org/D46329 llvm-svn: 331337
* [BranchFolding] Salvage DBG_VALUE instructions from empty blocksBjorn Pettersson2018-04-301-0/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch will introduce copying of DBG_VALUE instructions from an otherwise empty basic block to predecessor/successor blocks in case the empty block is eliminated/bypassed. It is currently only done in one identified situation in the BranchFolding pass, before optimizing on empty block. It can be seen as a light variant of the propagation done by the LiveDebugValues pass, which unfortunately is executed after the BranchFolding pass. We only propagate (copy) DBG_VALUE instructions in a limited number of situations: a) If the empty BB is the only predecessor of a successor we can copy the DBG_VALUE instruction to the beginning of the successor (because the DBG_VALUE instruction is always part of the flow between the blocks). b) If the empty BB is the only successor of a predecessor we can copy the DBG_VALUE instruction to the end of the predecessor (because the DBG_VALUE instruction is always part of the flow between the blocks). In this case we add the DBG_VALUE just before the first terminator (assuming that the terminators do not impact the DBG_VALUE). A future solution, to handle more situations, could perhaps be to run the LiveDebugValues pass before branch folding? This fix is related to PR37234. It is expected to resolve the problem seen, when applied together with the fix in SelectionDAG from here: https://reviews.llvm.org/D46129 Reviewers: #debug-info, aprantl, rnk Reviewed By: #debug-info, aprantl Subscribers: ormris, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D46184 llvm-svn: 331183
* [SelectionDAG] Improve selection of DBG_VALUE using a PHI node resultBjorn Pettersson2018-04-302-0/+349
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building the selection DAG at ISel all PHI nodes are selected and lowered to Machine Instruction PHI nodes before we start to create any SDNodes. So there are no SDNodes for values produced by the PHI nodes. In the past when selecting a dbg.value intrinsic that uses the value produced by a PHI node we have been handling such dbg.value intrinsics as "dangling debug info". I.e. we have not created a SDDbgValue node directly, because there is no existing SDNode for the PHI result, instead we deferred the creationg of a SDDbgValue until we found the first use of the PHI result. The old solution had a couple of flaws. The position of the selected DBG_VALUE instruction would end up quite late in a basic block, and for example not directly after the PHI node as in the LLVM IR input. And in case there were no use at all in the basic block the dbg.value could be dropped completely. This patch introduces a new VREG kind of SDDbgValue nodes. It is similar to a SDNODE kind of node, but it refers directly to a virtual register and not a SDNode. When we do selection for a dbg.value that is using the result of a PHI node we can do a lookup of the virtual register directly (as it already is determined for the PHI node) and create a SDDbgValue node immediately instead of delaying the selection until we find a use. This should fix a problem with losing debug info at ISel as seen in PR37234 (https://bugs.llvm.org/show_bug.cgi?id=37234). It does not resolve PR37234 completely, because the debug info is dropped later on in the BranchFolder (see D46184). Reviewers: #debug-info, aprantl Reviewed By: #debug-info, aprantl Subscribers: rnk, gbedwell, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D46129 llvm-svn: 331182
* Fix a bug that prevents global variables from having a DW_OP_deref.Adrian Prantl2018-04-271-0/+41
| | | | | | | | | | | | | | For local variables the first DW_OP_deref is consumed by turning the location kind into a memeory location, but that only makes sense for values that are in a register to begin with, which cannot happen for global variables that are attached to a symbol. rdar://problem/39741860 This reapplies r330970 after fixing an uncovered bug in r331086 and working around the situation caused by it. llvm-svn: 331090
* Revert "Fix a bug that prevents global variables from having a DW_OP_deref."Adrian Prantl2018-04-261-38/+0
| | | | | | This reverts commit r3309704 while investigating bot breakage. llvm-svn: 330993
* Fix a bug that prevents global variables from having a DW_OP_deref.Adrian Prantl2018-04-261-0/+38
| | | | | | | | | | | For local variables the first DW_OP_deref is consumed by turning the location kind into a memeory location, but that only makes sense for values that are in a register to begin with, which cannot happen for global variables that are attached to a symbol. rdar://problem/39741860 llvm-svn: 330970
* [MIR] Add support for debug metadata for fixed stack objectsFrancis Visoiu Mistrih2018-04-251-2/+2
| | | | | | | | | | | | | | | Debug var, expr and loc were only supported for non-fixed stack objects. This patch adds the following fields to the "fixedStack:" entries, and renames the ones from "stack:" to: * debug-info-variable * debug-info-expression * debug-info-location Differential Revision: https://reviews.llvm.org/D46032 llvm-svn: 330859
* [DebugInfo] Use WithColor for more debug line warningsAndrew Ng2018-04-202-2/+2
| | | | | | | | | | Updated two more debug line related warnings to use WithColor. This was necessary to ensure consistent output order of the warnings on Windows for debug line tests. Differential Revision: https://reviews.llvm.org/D45871 llvm-svn: 330440
* [DebugInfo] Fix for split dwarf test on Windows (NFC)Andrew Ng2018-04-201-1/+1
| | | | | | | | | On Windows, %llc_dwarf automatically adds -mtriple causing this test to error. Changed %llc_dwarf to llc. Differential Revision: https://reviews.llvm.org/D45869 llvm-svn: 330414
* Fix macosx build broken by r330249Pavel Labath2018-04-181-0/+41
| | | | | | | | | | | | | It seems llc crashes when targetting darwin with split-dwarf (pr37164). This happens on all inputs, not just the one I added in the above commit. Work around the issue by hardcoding the target triple to linux, which is what all split-dwarf tests seem to be doing. As I don't know of a way to specify the os part of the triple without spelling out the architecture as well, I move the new test to the X86 folder. llvm-svn: 330265
* [DebugInfo] Sink related dbg users when sinking in InstCombineBjorn Pettersson2018-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When sinking an instruction in InstCombine we now also sink the DbgInfoIntrinsics that are using the sunken value. Example) When sinking the load in this input bb.X: %0 = load i64, i64* %start, align 4, !dbg !31 tail call void @llvm.dbg.value(metadata i64 %0, ...) br i1 %cond, label %for.end, label %for.body.lr.ph for.body.lr.ph: br label %for.body we now also move the dbg.value, like this bb.X: br i1 %cond, label %for.end, label %for.body.lr.ph for.body.lr.ph: %0 = load i64, i64* %start, align 4, !dbg !31 tail call void @llvm.dbg.value(metadata i64 %0, ...) br label %for.body In the past we haven't moved the dbg.value so we got bb.X: tail call void @llvm.dbg.value(metadata i64 %0, ...) br i1 %cond, label %for.end, label %for.body.lr.ph for.body.lr.ph: %0 = load i64, i64* %start, align 4, !dbg !31 br label %for.body So in the past we got a debug-use before the def of %0. And that dbg.value was also on the path jumping to %for.end, for which %0 never was defined. CodeGenPrepare normally comes to rescue later (when not moving the dbg.value), since it moves dbg.value instrinsics quite brutally, without really analysing if it is correct to move the intrinsic (see PR31878). So at the moment this patch isn't expected to have much impact, besides that it is moving the dbg.value already in opt, making the IR look more sane directly. This can be seen as a preparation to (hopefully) make it possible to turn off CodeGenPrepare::placeDbgValues later as a solution to PR31878. I also adjusted test/DebugInfo/X86/sdagsplit-1.ll to make the IR in the test case up-to-date with this behavior in InstCombine. Reviewers: rnk, vsk, aprantl Reviewed By: vsk, aprantl Subscribers: mattd, JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D45425 llvm-svn: 330243
* [DebugInfo][OPT] Fixing a couple of DI duplication bugs of CloneModuleRoman Tereshin2018-04-132-0/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As demonstrated by the regression tests added in this patch, the following cases are valid cases: 1. A Function with no DISubprogram attached, but various debug info related to its instructions, coming, for instance, from an inlined function, also defined somewhere else in the same module; 2. ... or coming exclusively from the functions inlined and eliminated from the module entirely. The ValueMap shared between CloneFunctionInto calls within CloneModule needs to contain identity mappings for all of the DISubprogram's to prevent them from being duplicated by MapMetadata / RemapInstruction calls, this is achieved via DebugInfoFinder collecting all the DISubprogram's. However, CloneFunctionInto was missing calls into DebugInfoFinder for functions w/o DISubprogram's attached, but still referring DISubprogram's from within (case 1). This patch fixes that. The fix above, however, exposes another issue: if a module contains a DISubprogram referenced only indirectly from other debug info metadata, but not attached to any Function defined within the module (case 2), cloning such a module causes a DICompileUnit duplication: it will be moved in indirecty via a DISubprogram by DebugInfoFinder first (because of the first bug fix described above), without being self-mapped within the shared ValueMap, and then will be copied during named metadata cloning. So this patch makes sure DebugInfoFinder visits DICompileUnit's referenced from DISubprogram's as it goes w/o re-processing llvm.dbg.cu list over and over again for every function cloned, and makes sure that CloneFunctionInto self-maps DICompileUnit's referenced from the entire function, not just its own DISubprogram attached that may also be missing. The most convenient way of tesing CloneModule I found is to rely on CloneModule call from `opt -run-twice`, instead of writing tedious unit tests. That feature has a couple of properties that makes it hard to use for this purpose though: 1. CloneModule doesn't copy source filename, making `opt -run-twice` report it as a difference. 2. `opt -run-twice` does the second run on the original module, not its clone, making the result of cloning completely invisible in opt's actual output with and without `-run-twice` both, which directly contradicts `opt -run-twice`s own error message. This patch fixes this as well. Reviewed By: aprantl Reviewers: loladiro, GorNishanov, espindola, echristo, dexonsmith Subscribers: vsk, debug-info, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D45593 llvm-svn: 330069
* [FastISel] Disable local value sinking by defaultReid Kleckner2018-04-112-3/+3
| | | | | | | | | | | | | | | | | | This is causing compilation timeouts on code with long sequences of local values and calls (i.e. foo(1); foo(2); foo(3); ...). It turns out that code coverage instrumentation is a great way to create sequences like this, which how our users ran into the issue in practice. Intel has a tool that detects these kinds of non-linear compile time issues, and Andy Kaylor reported it as PR37010. The current sinking code scans the whole basic block once per local value sink, which happens before emitting each call. In theory, local values should only be introduced to be used by instructions between the current flush point and the last flush point, so we should only need to scan those instructions. llvm-svn: 329822
* [CodeGen/Dwarf] Rename the "sizetype" synthetic type and add it to the ↵Pavel Labath2018-04-104-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | accelerator table Summary: This type is created on-demand and used as the base type for array ranges. Since it is "special", its construction did not go through the createTypeDIE function and so it was never inserted into the accelerator table, although it clearly belongs there. I add an explicit addAccelType call to insert it into the table. During review, we also decided to rename the type to something more unique to avoid confusion in case the user has own "sizetype" type. The new name for the type size __ARRAY_SIZE_TYPE__. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45445 llvm-svn: 329705
* Re-commit r329179 after fixing build&test issuesPavel Labath2018-04-041-3/+3
| | | | | | | | | | | - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
OpenPOWER on IntegriCloud