[all-commits] [llvm/llvm-project] ddc493: [DebugInfo][RemoveDIs] Don't allocate one DPMarker...

[Jeremy Morse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ddc493579fa1b7eed058c7ed8a5a6b5755a31953
      https://github.com/llvm/llvm-project/commit/ddc493579fa1b7eed058c7ed8a5a6b5755a31953
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2024-02-06 (Tue, 06 Feb 2024)

  Changed paths:
    M llvm/include/llvm/IR/Instruction.h
    M llvm/lib/IR/BasicBlock.cpp
    M llvm/lib/IR/DebugProgramInstruction.cpp
    M llvm/lib/IR/Instruction.cpp
    M llvm/lib/Transforms/Utils/Local.cpp
    M llvm/lib/Transforms/Utils/LoopRotationUtils.cpp
    M llvm/unittests/IR/BasicBlockDbgInfoTest.cpp

  Log Message:
  -----------
  [DebugInfo][RemoveDIs] Don't allocate one DPMarker per instruction (#79345)

This is an optimisation patch that shouldn't have any functional effect.
There's no need for all instructions to have a DPMarker attached to them,
because not all instructions have adjacent DPValues (aka dbg.values).

This patch inserts the appropriate conditionals into functions like
BasicBlock::spliceDebugInfo to ensure we don't step on a null pointer when
there isn't a DPMarker allocated. Mostly, this is a case of calling
createMarker occasionally, which will create a marker on an instruction
if there isn't one there already.

Also folded into this is the use of adoptDbgValues, which is a natural
extension: if we have a sequence of instructions and debug records:

    %foo = add i32 %0,...
    # dbg_value { %foo, ...
    # dbg_value { %bar, ...
    %baz = add i32 %...
    %qux = add i32 %...

and delete, for example, the %baz instruction, then the dbg_value records
would naturally be transferred onto the %qux instruction (they "fall down"
onto it). There's no point in creating and splicing DPMarkers in the case
shown when %qux doesn't have a DPMarker already, we can instead just change
the owner of %baz's DPMarker from %baz to %qux. This also avoids calling
setParent on every DPValue.

Update LoopRotationUtils: it was relying on each instruction having it's
own distinct end(), so that we could express ranges and lack-of-ranges.
That's no longer true though: so switch to storing the range of DPValues on
the next instruction when we want to consider it's range next time around
the loop (see the nearby comment).