Page MenuHomePhabricator
Feed Advanced Search

Today

jmorse updated the diff for D66412: [DebugInfo][LiveDebugValues] Don't drop variable location tracking data across block boundaries.

Update: I noticed that in moving transferTerminatorInst, I'd changed the "process" method to always return false, so I've removed its return code.

Tue, Aug 20, 8:57 AM · Restricted Project
jmorse added a comment to D64595: [Debuginfo][SROA] Need to handle dbg.value in SROA pass..

Adrian wrote:

Stepping back a bit: Is the result of SROA multiple smaller allocas?

If SROA is only creating new allocas, then describing them with dbg.declares should do no harm, since a later call to LowerDbgDeclare would truncate their range by inserting new dbg.values at every load. But if SROA is inserting the load, we do need to make sure that the loaded value is tracked by a dbg.value (potentially in addition to tracking the alloca with a dbg.declare). So I guess my question is, where are loads for the SROAed allocas generated?

Tue, Aug 20, 6:30 AM · Restricted Project, debug-info
jmorse updated subscribers of D66467: [Codegen] skip debug instr to avoid code change.

Indeed, this'll need a MIR test for the BranchFolding pass to check for future regressions, and to demonstrate that this patch fixes the bug report. There are some MIR test examples in the llvm/test/CodeGen/MIR/X86 directory.

Tue, Aug 20, 4:42 AM · Restricted Project

Yesterday

jmorse updated the diff for D66412: [DebugInfo][LiveDebugValues] Don't drop variable location tracking data across block boundaries.

Adjust comment wordings

Mon, Aug 19, 9:27 AM · Restricted Project
jmorse added a comment to D64595: [Debuginfo][SROA] Need to handle dbg.value in SROA pass..

Looking good, and this produces the ~3% increase in variable locations in clang-3.4 builds like the previous revisions did too. It looks like the two xfailed tests are testing for the behaviour you're explicitly disabling: it's probably better to just delete them, as this is a deliberate decision to change that behaviour.

Mon, Aug 19, 9:17 AM · Restricted Project, debug-info
jmorse created D66412: [DebugInfo][LiveDebugValues] Don't drop variable location tracking data across block boundaries.
Mon, Aug 19, 4:44 AM · Restricted Project
jmorse committed rG176bbd5cde36: [DebugInfo] Make postra sinking of DBG_VALUEs subregister-safe (authored by jmorse).
[DebugInfo] Make postra sinking of DBG_VALUEs subregister-safe
Mon, Aug 19, 2:57 AM
jmorse committed rL369247: [DebugInfo] Make postra sinking of DBG_VALUEs subregister-safe.
[DebugInfo] Make postra sinking of DBG_VALUEs subregister-safe
Mon, Aug 19, 2:57 AM
jmorse closed D58191: [DebugInfo] Make postra sinking of DBG_VALUEs safe in the presence of subregisters.
Mon, Aug 19, 2:57 AM · Restricted Project
jmorse added inline comments to D58191: [DebugInfo] Make postra sinking of DBG_VALUEs safe in the presence of subregisters.
Mon, Aug 19, 2:48 AM · Restricted Project
jmorse updated the diff for D58191: [DebugInfo] Make postra sinking of DBG_VALUEs safe in the presence of subregisters.

/Really/ avoid nondeterminism this time.

Mon, Aug 19, 2:48 AM · Restricted Project
jmorse committed rGb58ba8aae710: [DebugInfo] Test for variable range un-coalescing (authored by jmorse).
[DebugInfo] Test for variable range un-coalescing
Mon, Aug 19, 2:07 AM
jmorse committed rL369243: [DebugInfo] Test for variable range un-coalescing.
[DebugInfo] Test for variable range un-coalescing
Mon, Aug 19, 2:06 AM
jmorse closed D66347: [DebugInfo] Test that LiveDebugVariables un-coalesces ranges over block boundaries.
Mon, Aug 19, 2:06 AM · Restricted Project

Fri, Aug 16

jmorse added a comment to D64595: [Debuginfo][SROA] Need to handle dbg.value in SROA pass..

Sorry for the long delay --

Fri, Aug 16, 7:01 AM · Restricted Project, debug-info
jmorse created D66347: [DebugInfo] Test that LiveDebugVariables un-coalesces ranges over block boundaries.
Fri, Aug 16, 6:52 AM · Restricted Project
jmorse added a comment to D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

Thanks for all the reviews!

Fri, Aug 16, 3:07 AM · Restricted Project
jmorse committed rG8b593480d33f: [DebugInfo] Handle complex expressions with spills in LiveDebugValues (authored by jmorse).
[DebugInfo] Handle complex expressions with spills in LiveDebugValues
Fri, Aug 16, 3:06 AM
jmorse committed rL369092: [DebugInfo] Handle complex expressions with spills in LiveDebugValues.
[DebugInfo] Handle complex expressions with spills in LiveDebugValues
Fri, Aug 16, 3:06 AM
jmorse closed D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.
Fri, Aug 16, 3:06 AM · Restricted Project

Thu, Aug 15

jmorse committed rGc476124bc898: [DebugInfo] Avoid crash from dropped fragments in LiveDebugValues (authored by jmorse).
[DebugInfo] Avoid crash from dropped fragments in LiveDebugValues
Thu, Aug 15, 10:52 AM
jmorse committed rL369026: [DebugInfo] Avoid crash from dropped fragments in LiveDebugValues.
[DebugInfo] Avoid crash from dropped fragments in LiveDebugValues
Thu, Aug 15, 10:49 AM
jmorse closed D66284: [DebugInfo] Avoid crash from dropped fragments in LiveDebugValues.
Thu, Aug 15, 10:48 AM · Restricted Project
jmorse updated the diff for D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

Rebase onto the crash-fixing patch in D66284. This patch now removes the crash-fixing workaround that salvages fragments from spilt expressions, in favour of a more generalised method to access the original unspilt expression. I've edited the details of that into the patch summary at the top.

Thu, Aug 15, 3:31 AM · Restricted Project
jmorse retitled D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues from [DebugInfo] LiveDebugValues: Don't drop fragment information when restoring spills to [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.
Thu, Aug 15, 3:16 AM · Restricted Project
jmorse added a child revision for D66284: [DebugInfo] Avoid crash from dropped fragments in LiveDebugValues: D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.
Thu, Aug 15, 3:08 AM · Restricted Project
jmorse added a parent revision for D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues: D66284: [DebugInfo] Avoid crash from dropped fragments in LiveDebugValues.
Thu, Aug 15, 3:08 AM · Restricted Project
jmorse created D66284: [DebugInfo] Avoid crash from dropped fragments in LiveDebugValues.
Thu, Aug 15, 3:08 AM · Restricted Project

Wed, Aug 14

jmorse added a comment to D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

I like the new patch! It looks like you discovered a few more pre-existing bugs though, so I'd suggest to do the following:

Wed, Aug 14, 9:46 AM · Restricted Project
jmorse committed rG90c2794bfc33: [DebugInfo] MCP: collect and update DBG_VALUEs encountered in local block (authored by jmorse).
[DebugInfo] MCP: collect and update DBG_VALUEs encountered in local block
Wed, Aug 14, 5:22 AM
jmorse committed rL368835: [DebugInfo] MCP: collect and update DBG_VALUEs encountered in local block.
[DebugInfo] MCP: collect and update DBG_VALUEs encountered in local block
Wed, Aug 14, 5:21 AM
jmorse closed D56265: [DebugInfo] MCP: collect and update DBG_VALUEs encountered in local block.
Wed, Aug 14, 5:21 AM · Restricted Project

Tue, Aug 13

jmorse updated the diff for D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

This update demonstrates one of the alternatives -- pointing the VarLoc object's DBG_VALUE at the unspilt DBG_VALUE allows the spill-restore code to access the correct expression upon restore. This requires slightly more logic when propagating locations, as we can't just blindly clone DBG_VALUEs any more.

Tue, Aug 13, 6:44 AM · Restricted Project
jmorse added a comment to D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

Naive question: Why doesn't the restore recognizer insert the exact same expression that was found by the spill recongizer, regardless of what expression is used to describe the spill? Or: what happens on this example with the +1 expression without this patch?

Tue, Aug 13, 3:17 AM · Restricted Project

Mon, Aug 12

jmorse added a comment to D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

This meaning, we're loosing those DBG_VALUEs, not that they are incorrect, right?

Mon, Aug 12, 1:59 PM · Restricted Project
jmorse added inline comments to D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.
Mon, Aug 12, 9:30 AM · Restricted Project
jmorse added a comment to D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

(ping -- back in office now, so can land this myself).

Mon, Aug 12, 8:59 AM · Restricted Project

Tue, Aug 6

jmorse updated the summary of D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.
Tue, Aug 6, 9:42 AM · Restricted Project
jmorse added a comment to D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.
In D65368#1615530, @vsk wrote:

Thanks. I think this looks reasonable, but don't have the bandwidth right now to test+merge a fix for llvm-9. + debug-info for more feedback/visibility.

Tue, Aug 6, 9:42 AM · Restricted Project
jmorse updated the diff for D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

Curses, previous update spliced in an old LiveDebugValues.cpp diff, this one should contain the revised LiveDebugValues.cpp, and the revised test modification, apologies for confusion.

Tue, Aug 6, 9:21 AM · Restricted Project
jmorse updated the diff for D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

Adjust test to positively check for correct fragment expressions after a spill and restore

Tue, Aug 6, 9:16 AM · Restricted Project

Sun, Aug 4

jmorse added a reviewer for D64595: [Debuginfo][SROA] Need to handle dbg.value in SROA pass.: jmorse.

NB, I haven't forgotten this (adding self as reviewer to keep track of it), but am out of office for a while. I think this hits a wider LLVM problem of values going in and out of memory (see discussion in [0] for example) and our ability to describe those circumstances.

Sun, Aug 4, 10:20 AM · Restricted Project, debug-info
jmorse updated the diff for D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.

Revise patch to not spill variable locations with complex (non-empty non-fragment) expressions, as we currently can't recover the original expression on restore.

Sun, Aug 4, 10:18 AM · Restricted Project

Sat, Jul 27

jmorse created D65368: [DebugInfo] Handle complex expressions of spilt locations in LiveDebugValues.
Sat, Jul 27, 6:30 AM · Restricted Project

Mon, Jul 22

jmorse accepted D64971: [SafeStack] Insert the deref after the offset.

So the deref ought to go after the arithmetic, and not before. Then someplace that knows the difference between values and locations can remove the deref so the resulting expression is ultimately correct in the DWARF?

Mon, Jul 22, 8:13 AM · Restricted Project

Jul 19 2019

jmorse added a comment to D64971: [SafeStack] Insert the deref after the offset.

This sounds similar to PR41675 -- sometimes the DWARF expression builder interprets a DW_OP_deref as an extra dereference, other times it interprets it as confirmation that the expression being built is a memory location.

Jul 19 2019, 9:50 AM · Restricted Project
jmorse accepted D64645: DAG: Handle dbg_value for arguments split into multiple subregs.

LGTM, thanks for the patch!

Jul 19 2019, 2:06 AM

Jul 18 2019

jmorse added a comment to D64595: [Debuginfo][SROA] Need to handle dbg.value in SROA pass..

Probably, it is OK if dbg.value was not originally _supposed_ to be a dbg.declare but was converted in this place.

Jul 18 2019, 5:55 AM · Restricted Project, debug-info
jmorse added a comment to D64645: DAG: Handle dbg_value for arguments split into multiple subregs.

Hmm, it looks like the extra DBG_VALUEs dropped in the msp430 test were legitimate locations for "b" -- if getUnderlyingArgRegs now fails but generates multiple {0,0} entries, the ArgRegsAndSizes.size() > 1 block on line 5487 generates no (well, zero sized) locations and returns true. Wheras before EmitFuncArgumentDbgValue returned false, and another code path found a location for "b".

Jul 18 2019, 3:30 AM

Jul 17 2019

jmorse added a comment to D64645: DAG: Handle dbg_value for arguments split into multiple subregs.

I got curious; the scenario I described happens in test/DebugInfo/MSP430/sdagsplit-1.ll, where one of the operands to a pair is a load.

Jul 17 2019, 5:12 AM
jmorse added a comment to D64645: DAG: Handle dbg_value for arguments split into multiple subregs.

This looks good to me, and I'm sort of familiar enough with the debug bits to approve. I've one concern about the change to getUnderlyingArgRegs though: previously it would fail-safe and return 0/$noreg if it encountered a node it didn't recognise. However now, if there's anything unrecognised in the middle of a vector/pair, the element will be silently skipped. That could lead to splitMultiRegDbgValue producing DBG_VALUEs with the wrong fragment offset, as it's unaware of the skipped element.

Jul 17 2019, 4:23 AM

Jul 15 2019

jmorse added a comment to D64595: [Debuginfo][SROA] Need to handle dbg.value in SROA pass..

This is a great bug find -- I'd no idea SROA ran twice! Applying this patch gives a ~3% increase in variable locations covered on a clang-3.4 build.

Jul 15 2019, 9:15 AM · Restricted Project, debug-info
jmorse added a comment to D58453: [DebugInfo][CGP] Limit placeDbgValues movement of dbg.value intrinsics.

! In D58453#1582991, @yurydelendik wrote:
Looks like I misunderstood meaning of *all*. I assumed that means DBG_VALUEs the refer the vreg def of the source instruction, excluding DBG_VALUEs that refer the same vreg def by the above instructions (in the same block). The test result above shows that collectDebugValues locates all DBG_VALUEs for the instruction even if it does not (re)define the value, but there are few instructions in the same block above that do. Is this the intended effect of this patch? If yes, we probably need to create more robust collectDebugValues-like method that will track lifetime of DBG_VALUEs.

Jul 15 2019, 6:14 AM · Restricted Project

Jul 12 2019

jmorse added a comment to D64630: [DebugInfo] Address performance regression with r364515.

Happily D58453 killing off a large amount of placeDbgValues activity significantly reduces DBG_VALUE grouping -- I don't have the numbers to hand, but I would say the density was almost an order of magnitude lower. The largest back in the benchmark I referred to was about ~120, and other large packs occurred much less frequently.

Jul 12 2019, 1:01 PM · Restricted Project
jmorse updated the diff for D58453: [DebugInfo][CGP] Limit placeDbgValues movement of dbg.value intrinsics.

I've added some changes to the patch that makes collectDebugValues behave in the way I described, returning all debug users of a VReg, optionally limited to only the basic block of the source MachineInst. This should be useful for testing; and it's immediately caused the test/DebugInfo/WebAssembly/dbg-value-move-reg-stackify.mir [0] test to fail. The output is:

Jul 12 2019, 9:33 AM · Restricted Project
jmorse created D64630: [DebugInfo] Address performance regression with r364515.
Jul 12 2019, 6:17 AM · Restricted Project
jmorse updated the diff for D58386: [DebugInfo] Pre-RA MachineSink: sink DBG_VALUEs that don't immediately follow the sunk instruction too.

Refresh this patch:

  • Rebase it onto the current open stack
  • Remove a bunch of needless attributes and metadata
Jul 12 2019, 2:50 AM · Restricted Project

Jul 11 2019

jmorse updated the diff for D58238: [DebugInfo] MachineSink: Insert undef DBG_VALUEs when sinking instructions, try to forward copies.

Split up subregister comparision into pairs, to make it clear we're comparing unsigneds.

Jul 11 2019, 8:52 AM · Restricted Project
jmorse updated the diff for D58191: [DebugInfo] Make postra sinking of DBG_VALUEs safe in the presence of subregisters.

Facepalm: it looks like I mucked up the diff before uploading, the patch originally came with this change to MachineSink, not just the test. Oooff.

Jul 11 2019, 8:36 AM · Restricted Project
jmorse added a comment to D58191: [DebugInfo] Make postra sinking of DBG_VALUEs safe in the presence of subregisters.
In D58191#1579194, @vsk wrote:

This test looks reasonable. Is D58238 the only MachineSink change you have queued up?

Jul 11 2019, 8:27 AM · Restricted Project

Jul 9 2019

jmorse committed rG9bebc65d7965: Revert r364515 and r364524 (authored by jmorse).
Revert r364515 and r364524
Jul 9 2019, 2:39 AM
jmorse committed rL365448: Revert r364515 and r364524.
Revert r364515 and r364524
Jul 9 2019, 2:37 AM

Jul 2 2019

jmorse updated the diff for D58191: [DebugInfo] Make postra sinking of DBG_VALUEs safe in the presence of subregisters.

Archaeology-ping: this patch avoids super/sub-register sinking leading to DBG_VALUEs referring to the wrong location, would be good for LLVM-9.

Jul 2 2019, 9:51 AM · Restricted Project

Jul 1 2019

jmorse added a comment to D58453: [DebugInfo][CGP] Limit placeDbgValues movement of dbg.value intrinsics.

The change will be OK: we rely on collectDebugValues in WebAssembly to locate instruction's debug values. And we worry only about these atm.

Jul 1 2019, 9:46 AM · Restricted Project
jmorse updated the diff for D58450: [DebugInfo][MachineCSE] Don't try to copy-propagate debuginfo for every COPY seen.

Rebase, update jump-insts in MIR test to latest version, address review comments (cheers).

Jul 1 2019, 9:31 AM · Restricted Project
jmorse committed rGd2b6665e3394: [DebugInfo] Avoid adding too much indirection to pointer-valued variables (authored by jmorse).
[DebugInfo] Avoid adding too much indirection to pointer-valued variables
Jul 1 2019, 2:40 AM
jmorse committed rL364736: [DebugInfo] Avoid adding too much indirection to pointer-valued variables.
[DebugInfo] Avoid adding too much indirection to pointer-valued variables
Jul 1 2019, 2:38 AM
jmorse closed D63429: [DebugInfo] Avoid adding too much indirection to pointer-valued variables.
Jul 1 2019, 2:38 AM · Restricted Project

Jun 28 2019

jmorse updated the diff for D63429: [DebugInfo] Avoid adding too much indirection to pointer-valued variables.

Vedant wrote:

This looks reasonable to me. Mind adding test coverage for simple tag_offset/fragment expressions?

Jun 28 2019, 9:38 AM · Restricted Project

Jun 27 2019

jmorse added a comment to D56265: [DebugInfo] MCP: collect and update DBG_VALUEs encountered in local block.

Ancient-ping on this, with the aim of it helping the placeDbgValues patch in. To re-summarise: this collects DBG_VALUEs to rewrite while walking through MachineCopyPropagation, rather than relying on the all-dbg-values-follow-the-defining-inst assumption.

Jun 27 2019, 10:12 AM · Restricted Project
jmorse committed rG3ca8f2b007c8: Add triple to a test I just added. (authored by jmorse).
Add triple to a test I just added.
Jun 27 2019, 4:55 AM
jmorse committed rL364524: Add triple to a test I just added..
Add triple to a test I just added.
Jun 27 2019, 4:55 AM
jmorse abandoned D61181: [WIP][DebugInfo] Avoid SelectionDAG un-necessarily debug-referring to dead VRegs.

Abandoning this WIP -- addressing the "values are in two places in SelectionDAG" problem isn't going to be so easy to solve.

Jun 27 2019, 3:24 AM · Restricted Project
jmorse committed rGd528bcd96573: [DebugInfo] Avoid register coalesing unsoundly changing DBG_VALUE locations (authored by jmorse).
[DebugInfo] Avoid register coalesing unsoundly changing DBG_VALUE locations
Jun 27 2019, 3:23 AM
jmorse committed rL364515: [DebugInfo] Avoid register coalesing unsoundly changing DBG_VALUE locations.
[DebugInfo] Avoid register coalesing unsoundly changing DBG_VALUE locations
Jun 27 2019, 3:23 AM
jmorse closed D56151: [DebugInfo] PR40010: Avoid register coalesing altering DBG_VALUE valuations.
Jun 27 2019, 3:23 AM · Restricted Project
jmorse added a comment to D56151: [DebugInfo] PR40010: Avoid register coalesing altering DBG_VALUE valuations.

Bjorn wrote:

My feeling is that the cases where we now lose some debug info is quite rare (at least for our DSP-C/DSP target), and the benefit of making the register coalescers handling of DBG_VALUE more sound outweigh that problem.

Jun 27 2019, 3:20 AM · Restricted Project

Jun 26 2019

jmorse added a comment to D56151: [DebugInfo] PR40010: Avoid register coalesing altering DBG_VALUE valuations.

I'm reading this as: "this patch make debug info more accurate by rejecting invalid DBG_VALUEs earlier on, but it overshoots the target a bit and also rejects a few(?) false positives". I support this approach, as we all want to move LLVM into the "more accurate" direction, assuming that the false positives are fixable and the ratio of rejected incorrect DBG_VALUEs to false positives is favorable.

Jun 26 2019, 2:48 AM · Restricted Project

Jun 25 2019

jmorse added a comment to D56151: [DebugInfo] PR40010: Avoid register coalesing altering DBG_VALUE valuations.

Ping: we should hammer out this review, seeing how the branch date for llvm-9 has been announced. Could I suggest that everyone is happy with the *implementation* of this patch, but that it's not yet agreed that it needs merging?

Jun 25 2019, 11:01 AM · Restricted Project

Jun 20 2019

jmorse updated the diff for D58453: [DebugInfo][CGP] Limit placeDbgValues movement of dbg.value intrinsics.

Freshen up patch to make it merge cleanly; check that DVI isn't null... not clear whether something has changed or if I uploaded a completely broken patch before.

Jun 20 2019, 10:03 AM · Restricted Project

Jun 18 2019

jmorse updated the diff for D63429: [DebugInfo] Avoid adding too much indirection to pointer-valued variables.

Account for DW_OP_LLVM_tag_offset when working out whether a DIExpression is "complex" or not.

Jun 18 2019, 8:30 AM · Restricted Project
jmorse added inline comments to D63429: [DebugInfo] Avoid adding too much indirection to pointer-valued variables.
Jun 18 2019, 7:39 AM · Restricted Project
jmorse added inline comments to D63429: [DebugInfo] Avoid adding too much indirection to pointer-valued variables.
Jun 18 2019, 7:35 AM · Restricted Project
jmorse updated the diff for D63429: [DebugInfo] Avoid adding too much indirection to pointer-valued variables.

Add an isComplex() method to DIExpression that detects when an expression could be interpreted as a memory location.

Jun 18 2019, 7:26 AM · Restricted Project
jmorse committed rGa1a4f5f12cc5: [DebugInfo][Docs] Document that prologue/epilogue variable location changes are… (authored by jmorse).
[DebugInfo][Docs] Document that prologue/epilogue variable location changes are…
Jun 18 2019, 1:51 AM
jmorse committed rL363654: [DebugInfo][Docs] Document that prologue/epilogue variable location changes are….
[DebugInfo][Docs] Document that prologue/epilogue variable location changes are…
Jun 18 2019, 1:50 AM
jmorse closed D63083: [DebugInfo][Docs] Document that prologue/epilogue variable location changes are ignored.
Jun 18 2019, 1:50 AM · Restricted Project

Jun 17 2019

jmorse created D63429: [DebugInfo] Avoid adding too much indirection to pointer-valued variables.
Jun 17 2019, 7:00 AM · Restricted Project
jmorse added a comment to D63083: [DebugInfo][Docs] Document that prologue/epilogue variable location changes are ignored.

Semi-ping: while this is approved, the extra interest suggested I should delay committing in case there's more discussion. Without hearing anything else, I'll land this in the next couple of days.

Jun 17 2019, 1:40 AM · Restricted Project
jmorse added a comment to D61181: [WIP][DebugInfo] Avoid SelectionDAG un-necessarily debug-referring to dead VRegs.

Sort-of ping at @bjope on this: this is fundamentally a speculative patch as I can't dig into the regressions being seen in D56151, and I have no expectations on other peoples time; however we'll need to think about whether those regressions block the placeDbgValues chain-of-things going into llvm-9, which will branch sometime soon (next month?). Similar to what I wrote in D56151, we have a choice of poisons for llvm-9:

  • Leave placeDbgValues as it is,
  • Disable placeDbgValues but don't commit D56151, which may cause dead variable locations to be resurrected during register coalescing,
  • Disable placeDbgValues, commit D56151, triggering the regressions @bjope saw there, which may or may not be alleviated by this patch.
Jun 17 2019, 1:37 AM · Restricted Project
jmorse updated the diff for D61181: [WIP][DebugInfo] Avoid SelectionDAG un-necessarily debug-referring to dead VRegs.

Address feedback / review

Jun 17 2019, 1:02 AM · Restricted Project

Jun 13 2019

jmorse committed rGd2cd9c23b4ec: [NFC] Sink a function call into LiveDebugValues::process (authored by jmorse).
[NFC] Sink a function call into LiveDebugValues::process
Jun 13 2019, 6:13 AM
jmorse added a comment to D62904: [DebugInfo] Honour variable fragments in LiveDebugValues.

Follow up in https://reviews.llvm.org/rL363259

Jun 13 2019, 6:13 AM · Restricted Project
jmorse committed rL363259: [NFC] Sink a function call into LiveDebugValues::process.
[NFC] Sink a function call into LiveDebugValues::process
Jun 13 2019, 6:08 AM
jmorse added a comment to D62904: [DebugInfo] Honour variable fragments in LiveDebugValues.

Blast, missed the final nit, will patch that in a second.

Jun 13 2019, 5:53 AM · Restricted Project
jmorse committed rGbf2b2f08b02d: [DebugInfo] Honour variable fragments in LiveDebugValues (authored by jmorse).
[DebugInfo] Honour variable fragments in LiveDebugValues
Jun 13 2019, 5:50 AM
jmorse committed rL363256: [DebugInfo] Honour variable fragments in LiveDebugValues.
[DebugInfo] Honour variable fragments in LiveDebugValues
Jun 13 2019, 5:49 AM
jmorse closed D62904: [DebugInfo] Honour variable fragments in LiveDebugValues.
Jun 13 2019, 5:48 AM · Restricted Project
jmorse committed rG181bf0cefb26: [DebugInfo] Use FrameDestroy to extend stack locations to end-of-function (authored by jmorse).
[DebugInfo] Use FrameDestroy to extend stack locations to end-of-function
Jun 13 2019, 3:02 AM
jmorse committed rL363245: [DebugInfo] Use FrameDestroy to extend stack locations to end-of-function.
[DebugInfo] Use FrameDestroy to extend stack locations to end-of-function
Jun 13 2019, 3:02 AM