<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/106419>106419</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Bad codeview (maybe others) debug info generated after the fastregalloc pass inserts instruction without debug information
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          TheJCAB
      </td>
    </tr>
</table>

<pre>
    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...
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzsWF9v4zYS_zTMyyCCRUm2_OAHx0nuUmR3iyDY9voSUNJIYkOROpKKk376w5CyY6e7V1xxwPXhFlnZ5p_5_5v52cI52WnEDSuuWHF9ISbfG7t57PGH3fbqojLN2-axlw72wkFrJt3AixTwMDmfwA-T81CbYZQKwdOpdtK1l0YD49u99L2ZPJjRy0H-JmjdMb6F1lh4Xebwk9SN2TuWbdnimi0Oz-Ui_pGOuDROFbQaOvRPUnvGS6nHybNsC1PGGV_DJctu4Mq8smxHK9kNsNVVvAsAoNDDIEZg2TUMwtc9bElptr06yuLrkysnu61UGDaz69-JPfwL4ieKhPaovQt6gjUkReOe8bJgfM2yw2XGt--H-RWdD4qyb0g_HDzfYatrxnfna7PZu4OxH0zIKVRnl0jIQeX7qkU_WU0Be99cXX9IzumluwdQxjw7UPI51sH3Unp_f1DjvLEIMuNQML6D0VtgvHhNmqpL3CiVSmRGG0LJTkN-jFvWVN1Tg7USFhkvv3uP8TTNVqv57fXdzeto0TlpNONljEM8U6b0KZqZXYHUL-YZQShl6hi8k7f4WvdCd_g0xMXZF8aLpzyRecj7LCAYli-efvlchLPxmRYfRKSrfl0V2JR5usBVWqRY3VBNLnPIycT5zWwgeANKVKhIJeP8XXplXrFJOWWc5_ePjOf0_2_0yDTu01Vf8bZoFutcpEVW8ay4SfBV-hXjHCa9l7p5l0wgVuifqoonspgj1VTdHLDsLLUxhsH1EOh7UwekM14qqZFAyosgxNVmDJ9jbsrgn6ZDzdYf10v-no_4OchupPNS1_67Sta_V7EsI3Kv4C6ogVoo5aTH0IG-BdATtdkfuLT6cy59Cz-PPYJFhS9CexiF9SAd-B6BcR7LibIktfN2Ct01gc_GE9KEBxlOt8bWeDmrBsbL6i30aMZXDthy8cFZsme5mGFQTR7uoCH_Vp7gq5-D6HD3aJc3scNL5yayrLxjfKUUuF4QkFu4A4vNVGOw3OJoDbST9T1axtfJqb8_9ajBSd0pvHQex1HqDqQOFxuspq5DG_Uh2f6ftNflAkKK-O5wO_RVWja1UPAirBSVQthLpUAbD643exCOGs1LuIcvSKaYqespuK43k2qS83xJB07LcUQPrTUDhJBypWq4_LKAQUidVDVcjlZqfylaj_ZSKMV4GFaux8aBMwOCkl3vv9cs39tLbuvX4PXuy4__IISmBcu2nV2GHhFCdqnmIqWSyzkV_c8kuNhZHI2jVyqHYqdkZYV9Y8Uu9rBi5yw9QwdJLLVuXqyod7HiCmiP3waHwtYaWHF9bMa5bf6Cdu229_fLfKwtqoz_-SZMY3RnsRuEeyZfqz48FVRK9OGRJAnLwkk5jErW0oeYuPFs6Xj8fxgTsnTubRnc6AYGUfehI5omdsMjcXv65XNafiKS9HXGygNheTWTr3TVr1Ylpk3b5C2m60qkN8n5QMiI3sQ_uHuA62kYYUsYgFvhPDxgJx192qoQB0MTvLTYBR9b4SIZO4h4RwfP4NN_02zqz5_Nj3-_c5SZRyvqZ3cvX1CjCyufzdcH7OKmxObL6B5wb6X3qD9ElTiTFkNoLCeo-PTla8ZtHOHfwfLHe__HzV8KN98c14zzP0w3zWsHAjTuTwc3SO2toSnZQPUWB-ooYrkJ3czD_OTQ4TtU8B-kbk0Cj3EMJ0kCFoUzmgwhCXfQTXPtOqlrBBlnuMZ9Anfx_a_0lU0Z0dDMpRFZG-08DXjGebRbewMP1z8TKr2BCmFy2NCIdPI3DGYGUj6g9gGDJEUodSRJZEiFSiLN03UCj1j3WhL3eotzObh4jMnBdxLjpsrhPyeSbOIUd14GkkFDmKQaMjtSAycGjAyMjKMVvzenkl1kSL7HNyIkStSYwFY34CaLgJpG_MwU3qAyvgfUDUwjDMI-R5ejRvlBaSCTpg1t6Kz5XU0elPBEeXaw7zFyGiVb9HIIV_49K5EOGvRoB6Jx0TThoUONVnhsoJXW-fOCcoHFSF2rqcEYRUsYDWVQi8kdEj0zN-GhF_qc0BCVGyIbosjse7Q4FwcFylpjQUl0gfYdmeKzNnu4v__6Cfao1DGea6o1qOeEHXjd6Y8AobJ6_D043KmrxKtE7SehQpxDMZh3Rga9eMETXATFXywd-Kg7ZOQY2GjCnIqPqTnPx5zFORhKOk_nTk2OoT7P23lowU1uxDqUIcFlQDuDV9huClkXnSCZUCHlKyr7RmwCdIlmzugVR-wSbEOlRM89FV5FJDwgV2pqRNNQoSXz9-LNJUCVOvN5mPScHWziZJ2zMIPTmSRJLppN1qyztbjATbriebnM1nl20W-WTblKebauiqoul1naliteNuuqWuZN1abrC7nhC54vSl6my4LzLOFtuyyahpctX2VVlrJ8gYOQKlHqZUiM7S5CpW7SxTJP1xfha6kLv09xHsJCu8Sli-sLu6FLl9XUOZYvKEPuXYyXXuHmSkSvXiTuqfIG8VYhGPpi4ohpvJfQSfUFzh5TJpw_kJPQqyktaP1ZD_tGn7ZDCODFZNWm934Mv4nwW8ZvO-n7qUpqMzB-S8bOL5ejNb9i7Rm_DS46xm_nGLxs-L8CAAD__5NeEtk">