summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/X86
Commit message (Collapse)AuthorAgeFilesLines
...
* [SROA] Disable non-whole-alloca splits by defaultHiroshi Inoue2017-12-181-2/+1
| | | | | | | This patch introduce a switch to control splitting of non-whole-alloca slices with default off. The switch will be default on again after fixing an issue reported in PR35657. llvm-svn: 320958
* Revert "Recommit "[DWARFv5] Dump an MD5 checksum in the line-table header.""Paul Robinson2017-12-151-10/+11
| | | | | | | This reverts commit 0afef672f63f0e4e91938656bc73424a8c058bfc. Still failing at runtime on bots. llvm-svn: 320888
* Recommit "[DWARFv5] Dump an MD5 checksum in the line-table header."Paul Robinson2017-12-151-11/+10
| | | | | | | | | | | Adds missing support for DW_FORM_data16. Update of r320852, fixing the unittest to use a hand-coded struct instead of std::array to guarantee data layout. Differential Revision: https://reviews.llvm.org/D41090 llvm-svn: 320886
* Revert "[DWARFv5] Dump an MD5 checksum in the line-table header."Paul Robinson2017-12-151-10/+11
| | | | | | Unit test fails on some bots. llvm-svn: 320857
* [DWARFv5] Dump an MD5 checksum in the line-table header.Paul Robinson2017-12-151-11/+10
| | | | | | | | Adds missing support for DW_FORM_data16. Differential Revision: https://reviews.llvm.org/D41090 llvm-svn: 320852
* EmitFuncArgumentDbgValue: Prefer stack slots over registers for stack argumentsAdrian Prantl2017-12-141-0/+76
| | | | | | | | | | | | | | | | | | While investigating LLVM PR22316 (http://llvm.org/bugs/show_bug.cgi?id=22316) I started wondering if it were not always preferable to emit the initial DBG_VALUEs for stack arguments as FI locations instead of describing the first register they get copied into. The advantage of doing this is that the arguments will be available as soon as the stack is setup. As illustrated by the testcase in the PR, the first copy of the FI into a register may be sunk by MachineSink.cpp into a later basic block. By describing the argument on the stack, we nicely circumvent this problem. <rdar://problem/19583723> Differential Revision: https://reviews.llvm.org/D41135 llvm-svn: 320758
* [MachineOperand][MIR] Add isRenamable to MachineOperand.Geoff Berry2017-12-122-3/+3
| | | | | | | | | | | | | | | | | | Summary: Add isRenamable() predicate to MachineOperand. This predicate can be used by machine passes after register allocation to determine whether it is safe to rename a given register operand. Register operands that aren't marked as renamable may be required to be assigned their current register to satisfy constraints that are not captured by the machine IR (e.g. ABI or ISA constraints). Reviewers: qcolombet, MatzeB, hfinkel Subscribers: nemanjai, mcrosier, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D39400 llvm-svn: 320503
* [NFC] Change the string offsets table tests to generate the object on the flyWolfgang Pieb2017-12-098-0/+1226
| | | | | | | | which enables us to remove the test scripts and object files from the repository. https://reviews.llvm.org/D40914 llvm-svn: 320227
* [DebugInfo] Use llc instead of llc_dwarf to fix this test.Davide Italiano2017-12-081-1/+1
| | | | | | | We work around the fact that some platforms add a triple when they expand llc_dwarf in lit. llvm-svn: 320164
* [DebugInfo] Move this test to X86/ now that it specifies a triple.Davide Italiano2017-12-071-0/+57
| | | | | | Should bring back the arm/arm64 bots. Reported by Yvan Roux. llvm-svn: 320057
* [MC/Dwarf] Use the older DWARF linetables format on Darwin.Davide Italiano2017-12-071-3/+3
| | | | | | | | | | dsymutil doesn't yet understand the new format and the change, among others, breaks a large fraction of the debugger tests on mac OS. rdar://problem/35856354 llvm-svn: 319995
* Re-submit r289925 (Update .debug_line section version to match DWARF version)Paul Robinson2017-12-042-4/+4
| | | | | | | | | | | | | | | Set the .debug_line version to match the requested DWARF version, except with a maximum of v4 because we don't support v5 yet. Previously Chromium had issues with this patch; see PR31407. Chromium tool issues have been addressed, so hopefully this will go through this time. Patch by Katya Romanova! Differential Revision: https://reviews.llvm.org/D38002 llvm-svn: 319699
* [CodeGen] Unify MBB reference format in both MIR and debug outputFrancis Visoiu Mistrih2017-12-042-3/+3
| | | | | | | | | | | | | | | | As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
* [DebugInfo] Bail out if making no progress dumping line tables.Paul Robinson2017-12-011-0/+97
| | | | llvm-svn: 319564
* Recommit rL319407: [SROA] enable splitting for non-whole-alloca loads and storesHiroshi Inoue2017-12-011-1/+2
| | | | | | Recommiting once reverted patch rL319407 after adding a check for bit vector size to avoid failures in some build bots. llvm-svn: 319522
* [MIR] Fix DebugInfo tests after r319445Francis Visoiu Mistrih2017-11-303-8/+8
| | | | llvm-svn: 319447
* Revert rL319407: [SROA] enable splitting for non-whole-alloca loads and stores Hiroshi Inoue2017-11-301-2/+1
| | | | | | This reverts commit rL319407 due to failures in some buildbot. llvm-svn: 319410
* [SROA] enable splitting for non-whole-alloca loads and storesHiroshi Inoue2017-11-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, SROA splits loads and stores only when they are accessing the whole alloca. This patch relaxes this limitation to allow splitting a load/store if all other loads and stores to the alloca are disjoint to or fully included in the current load/store. If there is no other load or store that crosses the boundary of the current load/store, the current splitting implementation works as is. The whole-alloca loads and stores meet this new condition and so they are still splittable. Here is a simplified motivating example. struct record { long long a; int b; int c; }; int func(struct record r) { for (int i = 0; i < r.c; i++) r.b++; return r.b; } When updating r.b (or r.c as well), LLVM generates redundant instructions on some platforms (such as x86_64, ppc64); here, r.b and r.c are packed into one 64-bit GPR when the struct is passed as a method argument. With this patch, the above example is compiled into only few instructions without loop. Without the patch, unnecessary loop-carried dependency is introduced by SROA and the loop cannot be eliminated by the later optimizers. Differential Revision: https://reviews.llvm.org/D32998 llvm-svn: 319407
* [CodeGen] Print register names in lowercase in both MIR and debug outputFrancis Visoiu Mistrih2017-11-2816-29/+29
| | | | | | | | | | | As part of the unification of the debug format and the MIR format, always print registers as lowercase. * Only debug printing is affected. It now follows MIR. Differential Revision: https://reviews.llvm.org/D40417 llvm-svn: 319187
* Control-Flow Enforcement Technology - Shadow Stack support (LLVM side)Oren Ben Simhon2017-11-261-6/+6
| | | | | | | | | | | | | | | | | | Shadow stack solution introduces a new stack for return addresses only. The HW has a Shadow Stack Pointer (SSP) that points to the next return address. If we return to a different address, an exception is triggered. The shadow stack is managed using a series of intrinsics that are introduced in this patch as well as the new register (SSP). The intrinsics are mapped to new instruction set that implements CET mechanism. The patch also includes initial infrastructure support for IBT. For more information, please see the following: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf Differential Revision: https://reviews.llvm.org/D40223 Change-Id: I4daa1f27e88176be79a4ac3b4cd26a459e88fed4 llvm-svn: 318996
* [DwarfDump] -debug-line=offset applies to .dwo too.Paul Robinson2017-11-221-0/+97
| | | | llvm-svn: 318856
* [DebugInfo] Dump a .debug_line section, including line-number program,Paul Robinson2017-11-221-0/+93
| | | | | | | | without any compile units. Differential Revision: https://reviews.llvm.org/D40114 llvm-svn: 318842
* [DWARFv5] Support DW_FORM_strp in the .debug_line.dwo header.Paul Robinson2017-11-221-0/+107
| | | | | | | | | | | As a side effect, the .debug_line section will be dumped in physical order, rather than in the order that compile units refer to their associated portions of the .debug_line section. These are probably always the same order anyway, and no tests noticed the difference. Differential Revision: https://reviews.llvm.org/D39854 llvm-svn: 318839
* [DWARF] Fix handling of extended line-number opcodesPaul Robinson2017-11-221-0/+152
| | | | | | Differential Revision: https://reviews.llvm.org/D40200 llvm-svn: 318838
* Add back target triple to test which I accidentally removed.Adrian Prantl2017-11-101-0/+1
| | | | llvm-svn: 317912
* Move test into X86 subdirectory.Adrian Prantl2017-11-101-0/+124
| | | | llvm-svn: 317896
* Handle inlined variables in SelectionDAGBuilder::EmitFuncArgumentDbgValue().Adrian Prantl2017-11-081-2/+3
| | | | | | | | | | | | | | | | | In 2010 a commit with no testcase and no further explanation explicitly disabled the handling of inlined variables in EmitFuncArgumentDbgValue(). I don't think there is a good reason for this any more and re-enabling this adds debug locations for variables associated with an LLVM function argument in functions that are inlined into the first basic block. The only downside of doing this is that we may insert a DBG_VALUE before the inlined scope, but (1) this could be filtered out later, and (2) LiveDebugValues will not propagate it into subsequent basic blocks if they don't dominate the variable's lexical scope, so this seems like a small price to pay. rdar://problem/26228128 llvm-svn: 317702
* Reapply r317609 with a simpler sed script, thanks to Justin Bogner!Paul Robinson2017-11-071-0/+149
| | | | llvm-svn: 317634
* Revert r317609, test fails on one botPaul Robinson2017-11-071-149/+0
| | | | llvm-svn: 317628
* Convert a dwarfdump test from checked-in binary to assembler source.Paul Robinson2017-11-071-0/+301
| | | | llvm-svn: 317612
* [DWARFv5] Add new test for previous commit.Paul Robinson2017-11-071-0/+149
| | | | llvm-svn: 317609
* Implement salavageDebugInfo functionality for SelectionDAG.Adrian Prantl2017-10-241-0/+110
| | | | | | | | | | | | | | Similar to how llvm::salvagDebugInfo hooks into InstCombine, this adds a hook that can be invoked before an SDNode that is associated with an SDDbgValue is erased to capture the effect of the deleted node in a DIExpression. The motivating example is an SDDebugValue attached to an ADD operation that gets folded into a LOAD+OFFSET operation. rdar://problem/32121503 llvm-svn: 316525
* Re-land "[llvm-dwarfdump] Print type names in DW_AT_type DIEs"Jonas Devlieghere2017-10-106-11/+11
| | | | | | | | | | | | This patch adds printing for DW_AT_type DIEs like it is already the case for DW_AT_specification DIEs. This is a rather naive approach and only a start. We should have pretty printers for different languages. Recommit after being reverted in r315299. Differential revision: https://reviews.llvm.org/D36993 llvm-svn: 315316
* Revert "[llvm-dwarfdump] Print type names in DW_AT_type DIEs"Jonas Devlieghere2017-10-106-11/+11
| | | | | | This reverts commit r315297. llvm-svn: 315299
* [llvm-dwarfdump] Print type names in DW_AT_type DIEsJonas Devlieghere2017-10-106-11/+11
| | | | | | | | | | This patch adds printing for DW_AT_type DIEs like it is already the case for DW_AT_specification DIEs. This is a rather naive approach and only a start. We should have pretty printers for different languages. Differential revision: https://reviews.llvm.org/D36993 llvm-svn: 315297
* [DebugInfo] Insert DEBUG_VALUEs after each register redefinitionKarl-Johan Karlsson2017-10-051-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When reinserting debug values after register allocation, make sure to insert debug values after each redefinition of debug value register in the slot index range. The reason for this is that DwarfDebug will end the range of a debug variable when the physical reg is defined. For instructions with e.g. tied operands this result in prematurely ended debug range. This resolves pr34545 Patch by Karl-Johan Karlsson and Bjorn Pettersson Reviewers: rnk, aprantl Reviewed By: rnk Subscribers: bjope, llvm-commits Differential Revision: https://reviews.llvm.org/D38229 llvm-svn: 314974
* [DebugInfo] Correctly coalesce DBG_VALUEs that mix direct and indirect valuesReid Kleckner2017-10-032-2/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This should fix a regression introduced by r313786, which switched from MachineInstr::isIndirectDebugValue() to checking if operand 1 is an immediate. I didn't have a test case for it until now. A single UserValue, which approximates a user variable, may have many DBG_VALUE instructions that disagree about whether the variable is in memory or in a virtual register. This will become much more common once we have llvm.dbg.addr, but you can construct such a test case manually today with llvm.dbg.value. Before this change, we would get two UserValues: one for direct and one for indirect DBG_VALUE instructions describing the same variable. If we build separate interval maps for direct and indirect locations, we will end up accidentally coalescing identical DBG_VALUE intervals that need to remain separate because they are broken up by intervals of the opposite direct-ness. Reviewers: aprantl Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37932 llvm-svn: 314819
* Revert "Re-enable "[MachineCopyPropagation] Extend pass to do COPY source ↵Geoff Berry2017-10-032-2/+2
| | | | | | | | | | forwarding"" This reverts commit r314729. Another bug has been encountered in an out-of-tree target reported by Quentin. llvm-svn: 314814
* Re-enable "[MachineCopyPropagation] Extend pass to do COPY source forwarding"Geoff Berry2017-10-022-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issues addressed since original review: - Avoid bug in regalloc greedy/machine verifier when forwarding to use in an instruction that re-defines the same virtual register. - Fixed bug when forwarding to use in EarlyClobber instruction slot. - Fixed incorrect forwarding to register definitions that showed up in explicit_uses() iterator (e.g. in INLINEASM). - Moved removal of dead instructions found by LiveIntervals::shrinkToUses() outside of loop iterating over instructions to avoid instructions being deleted while pointed to by iterator. - Fixed ARMLoadStoreOptimizer bug exposed by this change in r311907. - The pass no longer forwards COPYs to physical register uses, since doing so can break code that implicitly relies on the physical register number of the use. - The pass no longer forwards COPYs to undef uses, since doing so can break the machine verifier by creating LiveRanges that don't end on a use (since the undef operand is not considered a use). [MachineCopyPropagation] Extend pass to do COPY source forwarding This change extends MachineCopyPropagation to do COPY source forwarding. This change also extends the MachineCopyPropagation pass to be able to be run during register allocation, after physical registers have been assigned, but before the virtual registers have been re-written, which allows it to remove virtual register COPY LiveIntervals that become dead through the forwarding of all of their uses. llvm-svn: 314729
* CodeView symbol dumper: use symbolic names for registersHans Wennborg2017-10-021-3/+3
| | | | | | https://reviews.llvm.org/D38469 llvm-svn: 314690
* [test] Don't verify .debug_line offsets in bitcode tests.Jonas Devlieghere2017-09-271-4/+4
| | | | | | | | The exact values of the .debug_line offsets should not be hard-coded in the checks for bitcode tests. Fixes: http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/543 llvm-svn: 314294
* [dwarfdump] Fix printing of .debug_line offset.Jonas Devlieghere2017-09-271-4/+4
| | | | | | | | | Fixes 32-bit buildbots: http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/542 http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/11533 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/11494 llvm-svn: 314291
* [dwarfdump] Add support for -debug-line=OFFSETJonas Devlieghere2017-09-271-2/+6
| | | | | | | | This patch adds support for passing an offset to -debug-line. Differential revision: https://reviews.llvm.org/D38240 llvm-svn: 314288
* [DebugInfo] Sort the SDDbgValue list before assuming it is in IR orderReid Kleckner2017-09-251-0/+149
| | | | | | | | | | | | | | | | | | | | | | | Summary: This code iterates the 'Orders' vector in parallel with the DbgValue list, emitting all DBG_VALUEs that occurred between the last IR order insertion point and the next insertion point. This assumes the SDDbgValue list is sorted in IR order, which it usually is. However, it is not sorted when a node with a debug value is replaced with another one. When this happens, TransferDbgValues is called, and the new value is added to the end of the list. The problem can be solved by stably sorting the list by IR order. Reviewers: aprantl, Ka-Ka Reviewed By: aprantl Subscribers: MatzeB, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D38197 llvm-svn: 314114
* Re-land r313825: "[IR] Add llvm.dbg.addr, a control-dependent version of ↵Reid Kleckner2017-09-214-2/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | | llvm.dbg.declare" The fix is to avoid invalidating our insertion point in replaceDbgDeclare: Builder.insertDeclare(NewAddress, DIVar, DIExpr, Loc, InsertBefore); + if (DII == InsertBefore) + InsertBefore = &*std::next(InsertBefore->getIterator()); DII->eraseFromParent(); I had to write a unit tests for this instead of a lit test because the use list order matters in order to trigger the bug. The reduced C test case for this was: void useit(int*); static inline void inlineme() { int x[2]; useit(x); } void f() { inlineme(); inlineme(); } llvm-svn: 313905
* Revert r313825: "[IR] Add llvm.dbg.addr, a control-dependent version of ↵Daniel Jasper2017-09-214-228/+2
| | | | | | | | | | | llvm.dbg.declare" .. as well as the two subsequent changes r313826 and r313875. This leads to segfaults in combination with ASAN. Will forward repro instructions to the original author (rnk). llvm-svn: 313876
* [SROA] Really remove associated dbg.declare when removing dead allocaMikael Holmen2017-09-212-2/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There already was code that tried to remove the dbg.declare, but that code was placed after we had called I->replaceAllUsesWith(UndefValue::get(I->getType())); on the alloca, so when we searched for the relevant dbg.declare, we couldn't find it. Now we do the search before we call RAUW so there is a chance to find it. An existing testcase needed update due to this. Two dbg.declare with undef were removed and then suddenly one of the two CHECKS failed. Before this patch we got call void @llvm.dbg.declare(metadata i24* undef, metadata !14, metadata !DIExpression(DW_OP_LLVM_fragment, 32, 24)), !dbg !15 call void @llvm.dbg.declare(metadata %struct.prog_src_register* undef, metadata !14, metadata !DIExpression()), !dbg !15 call void @llvm.dbg.value(metadata i32 0, metadata !14, metadata !DIExpression(DW_OP_LLVM_fragment, 0, 32)), !dbg !15 call void @llvm.dbg.value(metadata i32 0, metadata !14, metadata !DIExpression(DW_OP_LLVM_fragment, 32, 24)), !dbg !15 and with it we get call void @llvm.dbg.value(metadata i32 0, metadata !14, metadata !DIExpression(DW_OP_LLVM_fragment, 0, 32)), !dbg !15 call void @llvm.dbg.value(metadata i32 0, metadata !14, metadata !DIExpression(DW_OP_LLVM_fragment, 32, 24)), !dbg !15 However, the CHECKs in the testcase checked things in a silly order, so they only passed since they found things in the first dbg.declare. Now we changed the order of the checks and the test passes. Reviewers: rnk Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37900 llvm-svn: 313875
* Commit local changes that missed llvm.dbg.addrReid Kleckner2017-09-201-2/+4
| | | | llvm-svn: 313826
* [IR] Add llvm.dbg.addr, a control-dependent version of llvm.dbg.declareReid Kleckner2017-09-202-0/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This implements the design discussed on llvm-dev for better tracking of variables that live in memory through optimizations: http://lists.llvm.org/pipermail/llvm-dev/2017-September/117222.html This is tracked as PR34136 llvm.dbg.addr is intended to be produced and used in almost precisely the same way as llvm.dbg.declare is today, with the exception that it is control-dependent. That means that dbg.addr should always have a position in the instruction stream, and it will allow passes that optimize memory operations on local variables to insert llvm.dbg.value calls to reflect deleted stores. See SourceLevelDebugging.rst for more details. The main drawback to generating DBG_VALUE machine instrs is that they usually cause LLVM to emit a location list for DW_AT_location. The next step will be to teach DwarfDebug.cpp how to recognize more DBG_VALUE ranges as not needing a location list, and possibly start setting DW_AT_start_offset for variables whose lifetimes begin mid-scope. Reviewers: aprantl, dblaikie, probinson Subscribers: eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D37768 llvm-svn: 313825
* Re-land "[DebugInfo] Insert DW_OP_deref when spilling indirect DBG_VALUEs"Reid Kleckner2017-09-204-3/+308
| | | | | | | | | | | | | After r313775, it's easier to maintain a parallel BitVector of spilled locations indexed by location number. I wasn't able to build a good reduced test case for this iteration of the bug, but I added a more direct assertion that spilled values must use frame index locations. If this bug reappears, it won't only fire on the NEON vector code that we detected it on, but on medium-sized integer-only programs as well. llvm-svn: 313786
OpenPOWER on IntegriCloud