summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/X86
Commit message (Collapse)AuthorAgeFilesLines
...
* [DebugInfo] Add calling convention support for DWARF and CodeViewReid Kleckner2016-06-081-0/+86
| | | | | | | | | | | | | | | | | | | | | Summary: Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If it is present and non-zero, the backend will emit it as a DW_AT_calling_convention attribute. On the CodeView side, we translate it to the appropriate enum for the LF_PROCEDURE record. I added a new LLVM vendor specific enum to the list of DWARF calling conventions. DWARF does not appear to attempt to standardize these, so I assume it's OK to do this until we coordinate with GCC on how to emit vectorcall convention functions. Reviewers: dexonsmith, majnemer, aaboud, amccarth Subscribers: mehdi_amini, llvm-commits Differential Revision: http://reviews.llvm.org/D21114 llvm-svn: 272197
* Debug Info: Don't emit bitfields in the DWARF4 format when tuning for GDB.Adrian Prantl2016-05-171-0/+3
| | | | | | | As discovered in PR27758, GDB does not fully support the DWARF 4 format. This patch ensures we always emit bitfields in the DWARF 2 when tuning for GDB. llvm-svn: 269827
* Debug Info: Don't emit a DW_AT_data_member_location for DWARF bitfields.Adrian Prantl2016-05-171-2/+3
| | | | | | | | | The DWARF spec states that a member entry may have either a DW_AT_data_member_location or a DW_AT_data_bit_offset, but not both. This fixes a bug found in PR 27758. llvm-svn: 269731
* Debug info: Don't emit a DW_AT_byte_size when emitting a DWARF4 bit field.Adrian Prantl2016-05-161-2/+7
| | | | | | | | | | The DWARF spec clearly states that a bit field member should have either a DW_AT_byte_size or a DW_AT_bit_size, but not both. Also the DW_AT_byte_size is redundant with the size of the type of the member. This fixes a bug found in PR 27758. llvm-svn: 269714
* Debug Info: Prevent DW_AT_abstract_origin from being emitted twiceAdrian Prantl2016-05-101-0/+57
| | | | | | | | | | | | for the same subprogram. This fixes a bug where DW_AT_abstract_origin is being emitted twice for the same subprogram if a function is both inlined and emitted in the same translation unit, by restoring the pre-r266446 behavior. http://reviews.llvm.org/D20072 llvm-svn: 269103
* Moved test case for r268323 to DebugInfo/X86 to unbreak aarch64.Wolfgang Pieb2016-05-031-0/+100
| | | | llvm-svn: 268339
* Reverting 268054 & 268063 as they caused PR27579.Amjad Aboud2016-04-3010-669/+19
| | | | llvm-svn: 268150
* Fixed LIT tests that was broken after change in r268054.Amjad Aboud2016-04-291-4/+0
| | | | llvm-svn: 268063
* Recommitted r264280 "Supporting all entities declared in lexical scope in ↵Amjad Aboud2016-04-299-15/+669
| | | | | | | | LLVM debug info." After fixing PR26942 in r267004. llvm-svn: 268054
* Read discriminators correctly from object file.Dehao Chen2016-04-282-0/+135
| | | | | | | | | | | | | | | Summary: This is the follow-up patch for http://reviews.llvm.org/D19436 * Update the discriminator reading algorithm to match the assignment algorithm. * Add test to cover the new algorithm. Reviewers: dnovillo, echristo, dblaikie Subscribers: danielcdh, dblaikie, echristo, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D19522 llvm-svn: 267945
* Debug info: Support DWARF4 bitfields via DW_AT_data_bit_offset.Adrian Prantl2016-04-281-0/+68
| | | | | | | | | | | | | The DWARF2 specification of DW_AT_bit_offset was written from the perspective of a big-endian machine with unclear semantics for other systems. DWARF4 deprecated DW_AT_bit_offset and introduced a new attribute DW_AT_data_bit_offset that simply counts the number of bits from the beginning of the containing entity regardless of endianness. After this patch LLVM emits DW_AT_bit_offset for DWARF 2 or 3 and DW_AT_data_bit_offset when DWARF 4 or later is requested. llvm-svn: 267895
* Verifier: Verify that each inlinable callsite of a debug-info-bearing functionAdrian Prantl2016-04-242-2/+4
| | | | | | | | | | | | | in a debug-info-bearing function has a debug location attached to it. Failure to do so causes an "!dbg attachment points at wrong subprogram for function" assertion failure when the inliner sets up inline scope info. rdar://problem/25878916 This reaplies r267320 without changes after fixing an issue in the OpenMP IR generator in clang. llvm-svn: 267370
* Revert "Verifier: Verify that each inlinable callsite of a ↵Adrian Prantl2016-04-242-4/+2
| | | | | | | | debug-info-bearing function" This reverts commit r267320 while investigating an OpenMP buildbot failure. llvm-svn: 267322
* Verifier: Verify that each inlinable callsite of a debug-info-bearing functionAdrian Prantl2016-04-242-2/+4
| | | | | | | | | | in a debug-info-bearing function has a debug location attached to it. Failure to do so causes an "!dbg attachment points at wrong subprogram for function" assertion failure when the inliner sets up inline scope info. rdar://problem/25878916 llvm-svn: 267320
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-2322-137/+137
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around DIType*. It is no longer legal to refer to a DICompositeType by its 'identifier:', and DIBuilder no longer retains all types with an 'identifier:' automatically. Aside from the bitcode upgrade, this is mainly removing logic to resolve an MDString-based reference to an actualy DIType. The commits leading up to this have made the implicit type map in DICompileUnit's 'retainedTypes:' field superfluous. This does not remove DITypeRef, DIScopeRef, DINodeRef, and DITypeRefArray, or stop using them in DI-related metadata. Although as of this commit they aren't serving a useful purpose, there are patchces under review to reuse them for CodeView support. The tests in LLVM were updated with deref-typerefs.sh, which is attached to the thread "[RFC] Lazy-loading of debug info metadata": http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html llvm-svn: 267296
* Fixed Dwarf debug info emission to skip DILexicalBlockFile entries.Amjad Aboud2016-04-211-0/+161
| | | | | | | | Before this fix, DILexicalBlockFile entries were skipped only in some cases and were not in other cases. Differential Revision: http://reviews.llvm.org/D18724 llvm-svn: 267004
* [SSP, 2/2] Create llvm.stackguard() intrinsic and lower it to LOAD_STACK_GUARDTim Shen2016-04-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | With this change, ideally IR pass can always generate llvm.stackguard call to get the stack guard; but for now there are still IR form stack guard customizations around (see getIRStackGuard()). Future SSP customization should go through LOAD_STACK_GUARD. There is a behavior change: stack guard values are not CSEed anymore, since we should never reuse the value in case that it has been spilled (and corrupted). See ssp-guard-spill.ll. This also cause the change of stack size and codegen in X86 and AArch64 test cases. Ideally we'd like to know if the guard created in llvm.stackprotector() gets spilled or not. If the value is spilled, discard the value and reload stack guard; otherwise reuse the value. This can be done by teaching register allocator to know how to rematerialize LOAD_STACK_GUARD and force a rematerialization (which seems hard), or check for spilling in expandPostRAPseudo. It only makes sense when the stack guard is a global variable, which requires more instructions to load. Anyway, this seems to go out of the scope of the current patch. llvm-svn: 266806
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-15152-500/+376
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
* Drop debug info for DISubprograms that are not referenced by anythingAdrian Prantl2016-04-091-3/+6
| | | | | | | | | | | | | | | | | | | | | This patch drops the debug info for all DISubprograms that are (a) not attached to an llvm::Function and (b) not indirectly reachable via inline scopes from any surviving Function and (c) not reachable from a type (i.e.: member functions). Background: I'm currently working on a patch to reverse the pointers between DICompileUnit and DISubprogram (for more info check Duncan's RFC on lazy-loading of debug info metadata http://lists.llvm.org/pipermail/llvm-dev/2016-March/097419.html). The idea is to remove the list of subprograms from DICompileUnit and instead point to the owning compile unit from each DISubprogram. After doing this all DISubprograms fulfilling the above criteria will be implicitly dropped unless we go through an extra effort to preserve them. http://reviews.llvm.org/D18477 <rdar://problem/25256815> llvm-svn: 265876
* Support the Nodebug emission kind for DICompileUnits.Adrian Prantl2016-04-081-0/+50
| | | | | | | | | | | | | | | | Sample-based profiling and optimization remarks currently remove DICompileUnits from llvm.dbg.cu to suppress the emission of debug info from them. This is somewhat of a hack and only borderline legal IR. This patch uses the recently introduced NoDebug emission kind in DICompileUnit to achieve the same result without breaking the Verifier. A nice side-effect of this change is that it is now possible to combine NoDebug and regular compile units under LTO. http://reviews.llvm.org/D18808 <rdar://problem/25427165> llvm-svn: 265861
* DwarfDebug: Support floating point constants in location lists.Adrian Prantl2016-04-082-66/+86
| | | | | | | | | | | | | | | | | | This patch closes a gap in the DWARF backend that caused LLVM to drop debug info for floating point variables that were constant for part of their scope. Floating point constants are emitted as one or more DW_OP_constu joined via DW_OP_piece. This fixes a regression caught by the LLDB testsuite that I introduced in r262247 when we stopped blindly expanding the range of singular DBG_VALUEs to span the entire scope and started to emit location lists with accurate ranges instead. Also deletes a now-impossible testcase (debug-loc-empty-entries). <rdar://problem/25448338> llvm-svn: 265760
* testcase gardening: update the emissionKind enum to the new syntax. (NFC)Adrian Prantl2016-04-01153-159/+159
| | | | llvm-svn: 265081
* Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl2016-03-3168-70/+70
| | | | | | | | | | | | | This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder into DICompileUnit. DIBuilder is not the right place for this enum to live in — a metadata consumer should not have to include DIBuilder.h. I also added a Verifier check that checks that the emission kind of a DICompileUnit is actually legal. http://reviews.llvm.org/D18612 <rdar://problem/25427165> llvm-svn: 265077
* Consider regmasks when computing register-based DBG_VALUE live rangesReid Kleckner2016-03-256-7/+130
| | | | | | | | | | | | | | Now register parameters that aren't saved to the stack or CSRs are considered dead after the first call. Previously the debugger would show whatever was in the register. Fixes PR26589 Reviewers: aprantl Differential Revision: http://reviews.llvm.org/D17211 llvm-svn: 264429
* Document the purpose of this testcase.Adrian Prantl2016-03-251-1/+2
| | | | llvm-svn: 264421
* Revert "Recommitted r263424 "Supporting all entities declared in lexical ↵Reid Kleckner2016-03-249-676/+18
| | | | | | | | | | | scope in LLVM debug info." After fixing PR26942 (the fix is included in this commit)." This reverts commit r264280. This broke building Chromium for iOS. We'll upload a reproducer to the PR soon. llvm-svn: 264334
* [debuginfo] Include dwo_name in the split unit to improve dwp diagnosticsDavid Blaikie2016-03-241-11/+15
| | | | | | | | | | | | | | | | | | | When multiple DWP files are merged together and duplicate DWO IDs are found it's currently difficult to give an actionable error message - the DW_AT_name of the CU could be provided, but might be identical (if the same source file is built into two different configurations), which doesn't help the user identify the problem. When no intermediate DWP files are generated, the path to the two DWO files could be provided - but is lost once the DWOs are merged into a DWP. So, include the name of the DWO (dwo_name) in the split file so that collissions involving a source CU from a DWP can be better diagnosed. (improvements to llvm-dwp using this to come shortly) llvm-svn: 264316
* Recommitted r263424 "Supporting all entities declared in lexical scope in ↵Amjad Aboud2016-03-249-18/+676
| | | | | | | | | | LLVM debug info." After fixing PR26942 (the fix is included in this commit). Differential Revision: http://reviews.llvm.org/D18350 llvm-svn: 264280
* Revert "Recommitted r261633 "Supporting all entities declared in lexical ↵Benjamin Kramer2016-03-148-587/+18
| | | | | | | | scope in LLVM debug info." After fixing PR26715 at r263379." This reverts commit r263424. Breaks self-host. llvm-svn: 263437
* Recommitted r261633 "Supporting all entities declared in lexical scope in ↵Amjad Aboud2016-03-148-18/+587
| | | | | | | | LLVM debug info." After fixing PR26715 at r263379. llvm-svn: 263424
* Don't crash when compiling inline assembler containing .file directives.Adrian Prantl2016-03-091-0/+65
| | | | | | | | | | Removing the assertion is safe to do because any module level inline assembly is always emitted first via AsmPrinter::doInitialization(). http://reviews.llvm.org/D16101 rdar://22690666 llvm-svn: 263033
* Document an anomaly in this testcase.Adrian Prantl2016-02-291-1/+6
| | | | llvm-svn: 262264
* Fix PR26585 by improving the promotion of DBG_VALUEs to DW_AT_locations.Adrian Prantl2016-02-297-19/+110
| | | | | | | | | | | | | | | When a variable is described by a single DBG_VALUE instruction we can often use a more efficient inline DW_AT_location instead of using a location list. This commit makes the heuristic that decides when to apply this optimization stricter by also verifying that the DBG_VALUE is live at the entry of the function (instead of just checking that it is valid until the end of the function). <rdar://problem/24611008> llvm-svn: 262247
* Revert r261633 "Supporting all entities declared in lexical scope in LLVM ↵Hans Wennborg2016-02-238-587/+18
| | | | | | | | debug info." This and the corresponding Clang change caused PR26715. llvm-svn: 261671
* Supporting all entities declared in lexical scope in LLVM debug info.Amjad Aboud2016-02-238-18/+587
| | | | | | Differential Revision: http://reviews.llvm.org/D15976 llvm-svn: 261633
* When printing MIR, output to errs() rather than outs().Justin Lebar2016-02-192-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Without this, this command $ llvm-run llc -stop-after machine-cp -o - <( echo '' ) outputs an error, because we close stdout twice -- once when closing the file opened for "-o", and again when closing outs(). Also clarify in the outs() definition that you can't ever call it if you want to open your own raw_fd_ostream on stdout. Reviewers: jroelofs, tstellarAMD Subscribers: jholewinski, qcolombet, dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D17422 llvm-svn: 261286
* [DWARFDebug] Fix another case of overlapping rangesKeno Fischer2016-02-031-0/+102
| | | | | | | | | | | | | | | Summary: In r257979, I added code to ensure that we wouldn't merge DebugLocEntries if the pieces they describe overlap. Unfortunately, I failed to cover the case, where there may have multiple active Expressions in the entry, in which case we need to make sure that no two values overlap before we can perform the merge. This fixed PR26148. Reviewers: aprantl Differential Revision: http://reviews.llvm.org/D16742 llvm-svn: 259696
* Followup to 258750; update more tests to use .p2align .Dan Gohman2016-01-261-1/+1
| | | | llvm-svn: 258755
* Reapply r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-159-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I originally reapplied this in 257550, but had to revert again due to bot breakage. The only change in this version is to allow either the TypeSize or the TypeAllocSize of the variable to be the one represented in debug info (hopefully in the future we can figure out how to encode the difference). Additionally, several bot failures following r257550, were due to optimizer bugs now fixed in r257787 and r257795. r257550 commit message was: ``` The follow extra changes were made to test cases: Manually making the variable be the actual type instead of a pointer to avoid pointer-size differences in generic code: LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll LLVM :: DebugInfo/Generic/varargs.ll Delete sizing information from debug info for the same reason (but the presence of the pointer was important to the test case): LLVM :: DebugInfo/Generic/restrict.ll LLVM :: DebugInfo/Generic/tu-composite.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/type-unique-simple2.ll Fixing an incorrect DW_OP_deref LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll Fixing a missing DW_OP_deref LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll Additionally, clang should no longer complain during bootstrap should no longer happen after r257534. The original commit message was: `` Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref `` ``` llvm-svn: 257850
* Re-Revert r257105 (Verifier debug info changes)Keno Fischer2016-01-139-18/+17
| | | | | | | While I investigate some new buildbot failures. This was originally reapplied as r257550 and r257558. llvm-svn: 257563
* Reapply r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-139-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The follow extra changes were made to test cases: Manually making the variable be the actual type instead of a pointer to avoid pointer-size differences in generic code: LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll LLVM :: DebugInfo/Generic/varargs.ll Delete sizing information from debug info for the same reason (but the presence of the pointer was important to the test case): LLVM :: DebugInfo/Generic/restrict.ll LLVM :: DebugInfo/Generic/tu-composite.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/type-unique-simple2.ll Fixing an incorrect DW_OP_deref LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll Fixing a missing DW_OP_deref LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll Additionally, clang should no longer complain during bootstrap should no longer happen after r257534. The original commit message was: ``` Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref ``` llvm-svn: 257550
* Temporarily revert r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-079-18/+17
| | | | | | | Looks like there's a case where clang generates debug info that triggers the new verifier check. Reverting while investigating. llvm-svn: 257107
* [Verifier] Check that debug values have proper sizeKeno Fischer2016-01-079-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref Reviewers: aprantl Differential Revision: http://reviews.llvm.org/D14276 llvm-svn: 257105
* Turn off lldb debug tuning by default for FreeBSDDimitry Andric2016-01-072-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: In rL242338, debugger tuning was introduced, and the tuning for FreeBSD was set to lldb by default. However, for the foreseeable future we still need to default to gdb tuning, since lldb is not ready for all of FreeBSD's architectures, and some system tools (like objcopy, etc) have not yet been adapted to cope with the lldb tuned format, which has .apple sections. Therefore, let FreeBSD use gdb by default for now. Reviewers: emaste, probinson Subscribers: llvm-commits, emaste Differential Revision: http://reviews.llvm.org/D15966 llvm-svn: 257103
* Added support for macro emission in dwarf (supporting DWARF version 4).Amjad Aboud2016-01-071-0/+67
| | | | | | Differential Revision: http://reviews.llvm.org/D15495 llvm-svn: 257060
* Fix PR24563 (LiveDebugVariables unconditionally propagates all DBG_VALUEs)Adrian Prantl2015-12-212-2/+102
| | | | | | | | | | | | | | | | LiveDebugVariables unconditionally propagates all DBG_VALUE down the dominator tree, which happens to work fine if there already is another DBG_VALUE or the DBG_VALUE happends to describe a single-assignment vreg but is otherwise wrong if the DBG_VALUE is coming from only one of the predecessors. In r255759 we introduced a proper data flow analysis scheduled after LiveDebugVariables that correctly propagates DBG_VALUEs across basic block boundaries. With the new pass in place, the incorrect propagation in LiveDebugVariables can be retired witout loosing any of the benefits where LiveDebugVariables happened to do the right thing. llvm-svn: 256188
* Clean up the processing of dbg.value in various placesKeno Fischer2015-12-196-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First up is instcombine, where in the dbg.declare -> dbg.value conversion, the llvm.dbg.value needs to be called on the actual loaded value, rather than the address (since the whole point of this transformation is to be able to get rid of the alloca). Further, now that that's cleaned up, we can remove a hack in the backend, that would add an implicit OP_deref if the argument to dbg.value was an alloca. This stems from before the existence of DIExpression and is no longer necessary since the deref can be expressed explicitly. Now, in order to make sure that the tests pass with this change, we need to correct the printing of DEBUG_VALUE comments to take into account the expression, which wasn't taken into account before. Unfortunately, for both these changes, there were a number of incorrect test cases (mostly the wrong number of DW_OP_derefs, but also a couple where the test itself was broken more badly). aprantl and I have gone through and adjusted these test case in order to make them pass with these fixes and in some cases to make sure they're actually testing what they are meant to test. Reviewers: aprantl Subscribers: dsanders Differential Revision: http://reviews.llvm.org/D14186 llvm-svn: 256077
* Hardcode the target in this testcase — it depends on the ABI.Adrian Prantl2015-12-171-1/+1
| | | | | | This fixes a failure on Windows buildbots. llvm-svn: 255919
* make this test less whitespace-sensitive.Adrian Prantl2015-12-171-1/+1
| | | | llvm-svn: 255913
* Rewrite test to use llvm-dwarfdump instead of checking for asm comments.Adrian Prantl2015-12-171-4/+12
| | | | llvm-svn: 255912
OpenPOWER on IntegriCloud