[all-commits] [llvm/llvm-project] ea3219: [DebugInfo][SelectionDAG] Fix position of salvaged...

[Orlando Cazalet-Hyams via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ea32197daa8517ff67c0691ad24d25eb5cf905f4
      https://github.com/llvm/llvm-project/commit/ea32197daa8517ff67c0691ad24d25eb5cf905f4
  Author: Orlando Cazalet-Hyams <orlando.hyams at sony.com>
  Date:   2024-06-06 (Thu, 06 Jun 2024)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
    A llvm/test/DebugInfo/X86/sdag-order.ll

  Log Message:
  -----------
  [DebugInfo][SelectionDAG] Fix position of salvaged 'dangling' DBG_VALUEs (#94458)

`SelectionDAGBuilder::handleDebugValue` has a parameter `Order` which
represents the insert-at position for the new DBG_VALUE. Prior to this patch
`SelectionDAGBuilder::SDNodeOrder` is used instead of the `Order` parameter.

The only code-paths where `Order != SDNodeOrder` are the two calls calls to
`handleDebugValue` from `salvageUnresolvedDbgValue`.
`salvageUnresolvedDbgValue` is called from `resolveOrClearDbgInfo` and
`dropDanglingDebugInfo`. The former is called after SelectionDAG completes one
block.

Some dbg.values can't be lowered to DBG_VALUEs right away. These get recorded
as 'dangling' - their order-number is saved - and get salvaged later through
`dropDanglingDebugInfo`, or if we've still got dangling debug info once the
whole block has been emitted, through `resolveOrClearDbgInfo`. Their saved
order-number is passed to `handleDebugValue`.

Prior to this patch, DBG_VALUEs inserted using these functions are inserted at
the "current" `SDNodeOrder` rather than the intended position that is passed to
the function.

Fix and add test.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications