[all-commits] [llvm/llvm-project] 19b65a: [DebugInfo][RemoveDIs] Add a DPValue implementatio...

[Jeremy Morse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 19b65a9c0284c12556512e8136352a7e1eb8dfa3
      https://github.com/llvm/llvm-project/commit/19b65a9c0284c12556512e8136352a7e1eb8dfa3
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M llvm/include/llvm/IR/DebugProgramInstruction.h
    M llvm/lib/IR/DebugProgramInstruction.cpp
    M llvm/lib/Transforms/InstCombine/InstCombineInternal.h
    M llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
    A llvm/test/DebugInfo/instcombine-sink-latest-assignment.ll

  Log Message:
  -----------
  [DebugInfo][RemoveDIs] Add a DPValue implementation for instcombine sinking (#77930)

In instcombine, when we sink an instruction into a successor block, we try
to clone and salvage all the variable assignments that use that Value. This
is a behaviour that's (IMO) flawed, but there are important use cases where
we want to avoid regressions, thus we're implementing this for the
non-instruction debug-info representation.

This patch refactors the dbg.value sinking code into it's own function, and
installs a parallel implementation for DPValues, the non-instruction
debug-info container. This is mostly identical to the dbg.value
implementation, except that we don't have an easy-to-access ordering
between DPValues, and have to jump through extra hoops to establish one in
the (rare) cases where that ordering is required.

The test added represents a common use-case in LLVM where these behaviours
are important: a loop has been completely optimised away, leaving several
dbg.values in a row referring to an instruction that's going to sink. The
dbg.values should sink in both dbg.value and RemoveDIs mode, and
additionally only the last assignment should sink.