[PATCH] D61600: [DebugInfo] More precise variable range for stack locations

[David Stenberg via Phabricator via llvm-commits]

dstenb added a comment.

Adding a comment about another hand-written example.



================
Comment at: lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1369-1370
+      // Use first DBG_VALUE instruction for check.
+      if (validThroughout(LScopes, MInsn, End)) {
+        RegVar->initializeDbgValue(DbgMI);
+        continue;
----------------
If we have input like this:

```
!13 = !DILocalVariable(name: "local", scope: !7, file: !1, line: 5, type: !14)
!14 = !DIBasicType(name: "unsigned int", size: 32, encoding: DW_ATE_unsigned)
[...]
  bb.0.entry:
    DBG_VALUE 123, $noreg, !13, !DIExpression(), debug-location !16
    DBG_VALUE 456, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 0, 16), debug-location !18
    DBG_VALUE 789, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 16, 16), debug-location !18
    CALL64pcrel32 @bar, csr_64, implicit $rsp, implicit $ssp, implicit-def $rsp, implicit-def $ssp, debug-location !17
    RETQ debug-location !18
```

`buildLocationList()` will produce a single entry (a composite location description containing the 456 and 789 fragment). Then `MInsn` will be:

```
    DBG_VALUE 123, $noreg, !13, !DIExpression(), debug-location !16
```

and `DbgMI`:

```
DBG_VALUE 789, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 16, 16), debug-location !18
```

and `End` null. As `MInsn` covers the whole scope, we will produce a single location description, but with `DbgMI`, which is only one of the two fragmented debug values which the variable is described by:

```
                  DW_AT_location	(DW_OP_piece 0x2, DW_OP_constu 0x315, DW_OP_stack_value, DW_OP_piece 0x2)
```

That input is hand-modified, and perhaps we can never get such debug information here in DwarfDebug when running through the normal pass chain. Still, it feels a bit iffy that a size optimization may result in us dropping information. My feeling is that this framework code should be able to handle that type of silly input.

Maybe we should be conservative and only try to produce single location descriptions in the most obvious cases. The most conservative approach I guess would be to only produce single location descriptions when all debug values are the same. Another is perhaps only doing this if all debug values are non-fragmented?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61600/new/

https://reviews.llvm.org/D61600