This is an archive of the discontinued LLVM Phabricator instance.

[WIP][DebugInfo] Fix SelectionDAGs placement of phi-reading dbg.values
AbandonedPublic

Authored by jmorse on Nov 19 2018, 10:24 AM.

Details

Reviewers
None
Summary

This is a work-in-progress related to PR38754 [0], put up for visibility rather than review.

The test modified in this patch contained some FIXMEs added by the author when he noticed that DBG_VALUEs were being placed out of order. This patch fixes two of the FIXME'd placements, leaves one that isn't fixed, and marks up another incorrect DBG_VALUE placement that was pre-existing.

The cause is an interaction between source-IR-ordering and phi nodes: in the relevant BB, three phi nodes are read, which SelectionDAG pre-emptively allocates VRegs for. These are then brought into the DAG through CopyFromReg nodes. However, when emitted to a machine BB CopyFromReg doesn't create any instruction, and a nullptr entry is put into the IR-Location -> MachineInstr map. EmitSchedule can't place the DBG_VALUE there, so puts it one insn later than it would have otherwise.

The (rough) patch causes ProcessSourceNode to ignore SDNodes that didn't produce an instruction. That means subsequent SDNodes producing MachineInstrs get entered as valid locations in the IR-Location -> MachineInstr map, and EmitSchedule can emit DBG_VALUEs at the intended location.

The edge case is where an IR-Location / order-number doesn't have any MachineInstrs emitted at all: then the logic in EmitSchedule places DBG_VALUEs as early as it can, which is no different to how it behaves at the moment.

[0] https://bugs.llvm.org/show_bug.cgi?id=38754

Diff Detail

Event Timeline

jmorse created this revision.Nov 19 2018, 10:24 AM
jmorse abandoned this revision.Feb 8 2019, 6:53 AM

This turned out to have PR40427 burried at the bottom of it, and was fixed in r352350.

Herald added a project: Restricted Project. · View Herald TranscriptFeb 8 2019, 6:53 AM