[all-commits] [llvm/llvm-project] 0116ed: [DebugInfo][InstrRef] Don't use instr-ref for unop...

[Jeremy Morse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0116ed006929224a934d99bd3705812485969221
      https://github.com/llvm/llvm-project/commit/0116ed006929224a934d99bd3705812485969221
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2021-08-25 (Wed, 25 Aug 2021)

  Changed paths:
    M llvm/include/llvm/CodeGen/MachineFunction.h
    M llvm/lib/CodeGen/LiveDebugValues/LiveDebugValues.cpp
    M llvm/lib/CodeGen/LiveDebugVariables.cpp
    M llvm/lib/CodeGen/MachineFunction.cpp
    M llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
    M llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
    A llvm/test/DebugInfo/X86/instr-ref-opt-levels.ll

  Log Message:
  -----------
  [DebugInfo][InstrRef] Don't use instr-ref for unoptimised functions

InstrRefBasedLDV is marginally slower than VarlocBasedLDV when analysing
optimised code -- however, it's much slower when analysing code compiled
-O0.

To avoid this: don't use instruction referencing for -O0 functions. In the
"pure" case of unoptimised code, this won't really harm the debugging
experience because most variables won't have been promoted off the stack,
so can't go missing. It becomes more complicated when optimised code is
inlined into functions marked optnone; however these are rare, and as -O0
doesn't run many optimisations there should be little damage to the debug
experience as a result.

I've taken the opportunity to refactor testing for instruction-referencing
into a MachineFunction method, which seems the most appropriate place to
put it.

Differential Revision: https://reviews.llvm.org/D108585