[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