[all-commits] [llvm/llvm-project] faa2f9: [DebugInfo] Handle dbg.assigns in FastISel (#80734)

Jeremy Morse via All-commits all-commits at lists.llvm.org
Thu Feb 8 02:44:54 PST 2024


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

  Changed paths:
    M llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
    M llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
    A llvm/test/DebugInfo/X86/dont-drop-dbg-assigns-in-isels.ll

  Log Message:
  -----------
  [DebugInfo] Handle dbg.assigns in FastISel (#80734)

There are some rare circumstances where dbg.assign intrinsics can reach
FastISel. They are a more specialised kind of dbg.value intrinsic with
more information about the originating alloca. They only occur during
optimisation, but might reach FastISel through always_inlining an
optimised function into an optnone function.

This is a slight problem as it's not safe (for debug-info accuracy) to
ignore any intrinsics, and for RemoveDIs (the intrinsic-replacement
project) it causes a crash through an unhandled switch case. To get
around this, we can just treat the dbg.assign as a dbg.value (it's an
actual subclass) and use the variable location information from the
dbg.value fields. This loses a small amount of debug-info about stack
locations, but is more accurate than just ignoring the intrinsic.

(This has popped up deep in an LTO build of a large codebase while
testing RemoveDIs, I figured it'd be good to fix it for the
intrinsic-form at the same time, just to demonstrate the correct
behaviour).




More information about the All-commits mailing list