llvmbot
commented
3 weeks ago @llvm/issue-subscribers-debuginfo
Author: Juan Carlos Arevalo Baeza (TheJCAB)
This was found via Rust. Just compile this function *without optimizations* for x64 Windows:
```Rust
pub fn get_int(input: u32) -> Box<u32> {
let map = match A::B(input) {
A::B(file) => {
let mut contents = Box::new(5);
*contents += file;
contents
},
A::C => Box::new(42),
};
return map;
}
```
IR looks like this:
```LL
store i32 5, ptr %x.dbg.spill.i3, align 4
#dbg_declare(ptr %x.dbg.spill.i3, !1377, !DIExpression(), !1381)
; invoke alloc::alloc::exchange_malloc
%_4.i4 = invoke ptr @_ZN5alloc5alloc15exchange_malloc17h9b5ed8410e7151ebE(i64 4, i64 4)
to label %"_ZN5alloc5boxed12Box$LT$T$GT$3new17hb2f5d094a153b235E.exit7" unwind label %funclet_bb2.i5, !dbg !1383
!1381 = !DILocation(line: 255, scope: !1378, inlinedAt: !1382)
!1382 = distinct !DILocation(line: 9, scope: !1368) ; Inline callsite for Box::new(5)
!1383 = !DILocation(line: 257, scope: !1378, inlinedAt: !1382)
```
The relevant part is the "invoke" instruction. Note that it is force-inlined (by Rust's `Box::new()`), but I don't think that's relevant to this issue (I'll share if I reduce the repro further).
When single-stepping in the debugger to the `let mut contents = Box::new(5);` line, the `file` local variable will not show as alive, even though it should.
This snippet from ("llc -O0 main.bc -print-after-all") sheds some light:
```
$rcx = COPY %15:gr64, debug-location !42; X:\repos\rust\library\alloc\src\boxed.rs:257 @[ src/main.rs:9 ]
$rdx = COPY %15:gr64, debug-location !42; X:\repos\rust\library\alloc\src\boxed.rs:257 @[ src/main.rs:9 ]
CALL64pcrel32 @_ZN5alloc5alloc15exchange_malloc17h9b5ed8410e7151ebE, <regmask $bh $bl blah blah...>, implicit $rsp, implicit blah blah, debug-location !42; X:\repos\rust\library\alloc\src\boxed.rs:257 @[ src/main.rs:9 ]
...
# End machine code for function _ZN18MatchVariableRepro7get_int17h778e1dfd4fe19ba1E.
# *** IR Dump After Fast Register Allocator (regallocfast) ***:
# Machine code for function _ZN18MatchVariableRepro7get_int17h778e1dfd4fe19ba1E: NoPHIs, TracksLiveness, NoVRegs, TiedOpsRewritten
...
renamable $rdx = MOV32ri64 4
$rcx = COPY renamable $rdx, debug-location !42; X:\repos\rust\library\alloc\src\boxed.rs:257 @[ src/main.rs:9 ]
CALL64pcrel32 @_ZN5alloc5alloc15exchange_malloc17h9b5ed8410e7151ebE, <regmask $bh $bl blah blah...>, implicit $rsp, implicit blah blah, debug-location !42; X:\repos\rust\library\alloc\src\boxed.rs:257 @[ src/main.rs:9 ]
```
"renamable $rdx = MOV32ri64 4" is a new instruction introduced by this pass, and it is introduced without debug info. This is... reasonable, I guess, since it's new. It's just loading the constant "4" into RDX (to be used as size and alignment for the allocation, I believe). Technically, this instruction, and the subsequent one, still should belong to the same scope as the two instructions that they replace. And sure enough, they both end up marked as belonging to the same line of code.
But later, when the lifetime of the `file` local variable is determined, that generated first instruction is not included the ranges, causing the issue at hand.
I'm not sure where the core error lies (I don't know LLVM well enough). It could be in the optimization (the new instruction is generated from actual code, so it should have debug info). Or it could be in the later determination of the lifetime of the local variable, where the list of instruction ranges is determined.
I suspect the former is... arguable against because the new instruction is just "loading a constant" that could then be reused in a number of ways. But this is unoptimized code generation, so...
jmorse
TheJCAB
This was found via Rust. Just compile this function without optimizations for x64 Windows:
IR looks like this:
The relevant part is the "invoke" instruction. Note that it is force-inlined (by Rust's
Box::new()), but I don't think that's relevant to this issue (I'll share if I reduce the repro further).When single-stepping in the debugger to the
let mut contents = Box::new(5);line, thefilelocal variable will not show as alive, even though it should.This snippet from ("llc -O0 main.bc -print-after-all") sheds some light:
"renamable $rdx = MOV32ri64 4" is a new instruction introduced by this pass, and it is introduced without debug info. This is... reasonable, I guess, since it's new. It's just loading the constant "4" into RDX (to be used as size and alignment for the allocation, I believe). Technically, this instruction, and the subsequent one, still should belong to the same scope as the two instructions that they replace. And sure enough, they both end up marked as belonging to the same line of code.
But later, when the lifetime of the
filelocal variable is determined, that generated first instruction is not included the ranges, causing the issue at hand.I'm not sure where the core error lies (I don't know LLVM well enough). It could be in the optimization (the new instruction is generated from actual code, so it should have debug info). Or it could be in the later determination of the lifetime of the local variable, where the list of instruction ranges is determined.
I suspect the former is... arguable against because the new instruction is just "loading a constant" that could then be reused in a number of ways. But this is unoptimized code generation, so...