It looks like variables are being optimized away at mir-opt-level=2 when they should be retained for debugging purposes. For example, in the following program, a and b are not known to the debugger (on any platform):
pub fn example() {
let a = 1;
let b = 16;
foo(a + b); // break here
}
#[inline(never)]
fn foo(x: i32) {
std::process::exit(x);
}
This appears to be the result of MIR optimizations as going from -Zmir-opt-level=1 to -Zmir-opt-level=2 causes the calls to @llvm.dbg.value to disappear:
define void @_ZN7example7example17h6142df5531d284b7E() unnamed_addr #0 !dbg !6 {
start:
- call void @llvm.dbg.value(metadata i32 1, metadata !12, metadata !DIExpression()), !dbg !18
- call void @llvm.dbg.value(metadata i32 16, metadata !15, metadata !DIExpression()), !dbg !19
tail call fastcc void @_ZN7example3foo17he136a32a31d586dbE(), !dbg !20
unreachable, !dbg !21
}
godbolt
LLVM is able to perform this optimization while retaining debuginfo so we shouldn't interfere with that unless the user has opted into a higher level of MIR optimization where degrading debuggability is acceptable.
It looks like variables are being optimized away at
mir-opt-level=2when they should be retained for debugging purposes. For example, in the following program,aandbare not known to the debugger (on any platform):This appears to be the result of MIR optimizations as going from
-Zmir-opt-level=1to-Zmir-opt-level=2causes the calls to@llvm.dbg.valueto disappear:define void @_ZN7example7example17h6142df5531d284b7E() unnamed_addr #0 !dbg !6 { start: - call void @llvm.dbg.value(metadata i32 1, metadata !12, metadata !DIExpression()), !dbg !18 - call void @llvm.dbg.value(metadata i32 16, metadata !15, metadata !DIExpression()), !dbg !19 tail call fastcc void @_ZN7example3foo17he136a32a31d586dbE(), !dbg !20 unreachable, !dbg !21 }godbolt
LLVM is able to perform this optimization while retaining debuginfo so we shouldn't interfere with that unless the user has opted into a higher level of MIR optimization where degrading debuggability is acceptable.