LLVM's DWARF associates instruction from caller with source from inlined callee

[hubert-reinterpretcast]

Consider the following program:

__attribute__((optnone)) void f1(int x) { }
__attribute__((always_inline)) inline void f2(int *p, int x) {
  *p = 42; // moved outside of loop
  f1(x);
}
__attribute__((optnone)) void f3(int *p) { }
int main(int argc, char **argv) {
  int q;
  for (int x = 0; x < argc; ++x) {
    f2(&q, x);
  }
  f3(&q);
  return q;
}

Compiled with -O3 -g, the store of 42 is moved outside of the loop to just before the call to f3: https://godbolt.org/z/oYx7YqMhj

.LBB2_3:
        mov     dword ptr [rsp + 4], 42
        lea     rdi, [rsp + 4]
        call    f3(int*)

However, the lea instruction, which corresponds to &q in the call to f3 is associated with line 3 (*p = 42) in the DWARF:

Address            Line   Column File   ISA Discriminator OpIndex Flags
------------------ ------ ------ ------ --- ------------- ------- -------------
0x0000000000000000      1      0      0   0             0       0  is_stmt
0x0000000000000004      1     43      0   0             0       0  is_stmt prologue_end
0x0000000000000010      6      0      0   0             0       0  is_stmt
0x0000000000000015      6     44      0   0             0       0  is_stmt prologue_end
0x0000000000000020      7      0      0   0             0       0  is_stmt
0x0000000000000023      9     21      0   0             0       0  is_stmt prologue_end
0x0000000000000025      9      3      0   0             0       0
0x0000000000000027      0      3      0   0             0       0
0x0000000000000030      4      3      0   0             0       0  is_stmt
0x0000000000000037      9     29      0   0             0       0  is_stmt
0x0000000000000039      9     21      0   0             0       0
0x000000000000003b      9      3      0   0             0       0
0x000000000000003d      3      6      0   0             0       0  is_stmt
0x000000000000004a     12      3      0   0             0       0  is_stmt
0x000000000000004f     13     10      0   0             0       0  is_stmt
0x0000000000000053     13      3      0   0             0       0  epilogue_begin
0x000000000000005a     13      3      0   0             0       0  end_sequence

ranges.o:       file format elf64-x86-64

Disassembly of section .text:

0000000000000020 <main>:
      3d: c7 44 24 04 2a 00 00 00       movl    $0x2a, 0x4(%rsp)
      45: 48 8d 7c 24 04                leaq    0x4(%rsp), %rdi

Similarly, the lea instruction is represented as being inlined from f2:

0x000000b0:       DW_TAG_inlined_subroutine
                    DW_AT_abstract_origin       (0x00000059 "f2")
                    DW_AT_ranges        (indexed (0x0) rangelist = 0x00000010
                       [0x000000000000002b, 0x0000000000000037)
                       [0x000000000000003d, 0x000000000000004a))

Clang version info:

clang version 22.0.0git (https://github.com/llvm/llvm-project.git 7694856fddbb3fed10076aefec75c9b512cc352e)

Partial IR:

for.cond.cleanup:                                 ; preds = %for.body, %entry
  store i32 42, ptr %q, align 4, !dbg !52, !DIAssignID !61
  call void @f3(ptr noundef nonnull %q), !dbg !62
;   ...
!52 = !DILocation(line: 3, column: 6, scope: !53, inlinedAt: !59)
!53 = distinct !DISubprogram(name: "f2", scope: !1, file: !1, line: 2, type: !54, scopeLine: 2, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !56)
;   ...
!59 = distinct !DILocation(line: 10, column: 5, scope: !60)
;   ...
!62 = !DILocation(line: 12, column: 3, scope: !33)

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Hubert Tong (hubert-reinterpretcast)

Consider the following program: ```c __attribute__((optnone)) void f1(int x) { } __attribute__((always_inline)) inline void f2(int *p, int x) { *p = 42; // moved outside of loop f1(x); } __attribute__((optnone)) void f3(int *p) { } int main(int argc, char **argv) { int q; for (int x = 0; x < argc; ++x) { f2(&q, x); } f3(&q); return q; } ```

Compiled with -O3 -g, the store of 42 is moved outside of the loop to just before the call to f3: https://godbolt.org/z/oYx7YqMhj

.LBB2_3:
        mov     dword ptr [rsp + 4], 42
        lea     rdi, [rsp + 4]
        call    f3(int*)

However, the lea instruction, which corresponds to &q in the call to f3 is associated with line 3 (*p = 42) in the DWARF:

Address            Line   Column File   ISA Discriminator OpIndex Flags
------------------ ------ ------ ------ --- ------------- ------- -------------
0x0000000000000000      1      0      0   0             0       0  is_stmt
0x0000000000000004      1     43      0   0             0       0  is_stmt prologue_end
0x0000000000000010      6      0      0   0             0       0  is_stmt
0x0000000000000015      6     44      0   0             0       0  is_stmt prologue_end
0x0000000000000020      7      0      0   0             0       0  is_stmt
0x0000000000000023      9     21      0   0             0       0  is_stmt prologue_end
0x0000000000000025      9      3      0   0             0       0
0x0000000000000027      0      3      0   0             0       0
0x0000000000000030      4      3      0   0             0       0  is_stmt
0x0000000000000037      9     29      0   0             0       0  is_stmt
0x0000000000000039      9     21      0   0             0       0
0x000000000000003b      9      3      0   0             0       0
0x000000000000003d      3      6      0   0             0       0  is_stmt
0x000000000000004a     12      3      0   0             0       0  is_stmt
0x000000000000004f     13     10      0   0             0       0  is_stmt
0x0000000000000053     13      3      0   0             0       0  epilogue_begin
0x000000000000005a     13      3      0   0             0       0  end_sequence

ranges.o:       file format elf64-x86-64

Disassembly of section .text:

0000000000000020 <main>:
      3d: c7 44 24 04 2a 00 00 00       movl    $0x2a, 0x4(%rsp)
      45: 48 8d 7c 24 04                leaq    0x4(%rsp), %rdi

Similarly, the lea instruction is represented as being inlined from f2:

0x000000b0:       DW_TAG_inlined_subroutine
                    DW_AT_abstract_origin       (0x00000059 "f2")
                    DW_AT_ranges        (indexed (0x0) rangelist = 0x00000010
                       [0x000000000000002b, 0x0000000000000037)
                       [0x000000000000003d, 0x000000000000004a))

Clang version info:

clang version 22.0.0git (https://github.com/llvm/llvm-project.git 7694856fddbb3fed10076aefec75c9b512cc352e)

Partial IR:

for.cond.cleanup:                                 ; preds = %for.body, %entry
  store i32 42, ptr %q, align 4, !dbg !52, !DIAssignID !61
  call void @<!-- -->f3(ptr noundef nonnull %q), !dbg !62
;   ...
!52 = !DILocation(line: 3, column: 6, scope: !53, inlinedAt: !59)
!53 = distinct !DISubprogram(name: "f2", scope: !1, file: !1, line: 2, type: !54, scopeLine: 2, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !56)
;   ...
!59 = distinct !DILocation(line: 10, column: 5, scope: !60)
;   ...
!62 = !DILocation(line: 12, column: 3, scope: !33)

[jmorse]

Many thanks for the bug report! It looks like the first place this goes wrong is in LICM when the store is sunk out of the loop -- the value isn't yet fixed to be 42, but the source location is fixed to be the inlined-location of the store of 42. At that point the source location becomes "bonus coverage", i.e. a source location that can appear on a execution path with optimisations when it won't appear on the same path without optimisations (which is bad).

I think this is an awkward mix of expectations in LICM: it promotes the value for "q" so that the store can be sunk out of the loop, and uses DebugLoc::getMergedLocations to pick a source location for the store. Under normal circumstances this would see multiple loop users of the variable and merge their locations into line-zero, signalling that there's no good source location for the sunk store. However because there's only one loop user instruction of q according to LICM (the inlined store of line 42), there's only one source location to merge, which then "wins" and becomes the source location of the sunk store.

This is inherently tied to the fact that q starts uninitialized, but LLVM promotes it into SSA to sink the store, without there being an instruction to represent an initializing value. We need to be aware of that in LICM. (NB, I'm broadly absent for the next week and can't look too closely).

[dwblaikie]

Perhaps, technically, since the loop is guaranteed to execute at least once (or the program exhibits UB by reading from an uninitialized value when it return q from main), sinking the instruction can carry the location with it - since it won't give false coverage.

I'm not sure if LLVM is actually relying on that, though (you could try calling an external function that takes a pointer to q instead of returning q - if it still preserves the location in that case (where there may be no read of q) then it'd be a bug).

[hubert-reinterpretcast]

Even when q is initialized, the store (fed now from a phi node) is associated with the inlined statement: https://godbolt.org/z/3zh4ThYYG

  %6 = phi i32 [ 0, %2 ], [ 42, %8 ]
  store i32 %6, ptr %3, align 4, !dbg !54, !DIAssignID !63
; ...
!54 = !DILocation(line: 3, column: 6, scope: !55, inlinedAt: !61)

[hubert-reinterpretcast]

Perhaps, technically, since the loop is guaranteed to execute at least once (or the program exhibits UB by reading from an uninitialized value when it return q from main), sinking the instruction can carry the location with it - since it won't give false coverage.

The original concern of the bug report is that the machine instruction following the store (which sets up the argument to the call) is represented as part of the assignment statement as opposed to the call statement.

It sounds like there is more than one problem here: wrong IR (false coverage) and wrong DWARF from codegen.