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.