[PATCH] D95617: [DWARF] Inlined variables with no location should not have a DW_TAG_variable

[Jeremy Morse via Phabricator via llvm-commits]

jmorse added a comment.

In D95617#3300552 <https://reviews.llvm.org/D95617#3300552>, @ro wrote:

> `no-empty-child-vars.ll` FAILs on SPARC: the first
>
>   ; CHECK:     DW_TAG_subprogram
>   ; CHECK:       DW_AT_abstract_origin (0x{{[0-9a-f]*}} "foo")
>
> is missing completely and both `qux` and `croix` lack `DW_TAG_inlined_subroutine`.
>
> Any suggestion what to do about this?

Hi @ro,

I took a look at the DWARF produced when passing "-mtriple sparc--", to llc, which I've assumed is a good enough triple as it's replicated what you're describing. In the test, there's a single instruction with several inlining scopes:

  %add.i = add nsw i32 %quux, 12, !dbg !33

The debug-info describes it as being from the "foo" function, inlined into croix, and that's what the test expects to be in the DWARF. However, sparc applies some optimisations to the add instruction which makes it disappear from the line tables, which stops the inlining information from appearing in the DWARF, hence the test failure.

The simplest and most straightforwards fix is to change the "!dbg !34" attachment on the IR "ret" instruction in croix to "!dbg !33", and repeat for the other two functions (!16 -> !15 in foo, !25 -> !24 in qux). That makes the test pass for me locally, and matches the intention of the check, which is to look at the DWARF that's emitted. The changes avoids relying on the add instruction appearing in the output, which sparc seems to optimise away.

Before taking that path though, could I ask whether the sparc line table is correct: I've no good understanding of what's going on on sparc (there are instruction bundles, I think?). At the end of compilation, the MIR looks like this:

  RETL 8, implicit $o0, debug-location !29; test.c:2:16 @[ test.c:12:15 ] {
    $o0 = nsw ADDri killed $o0, 12, debug-location !29; test.c:2:16 @[ test.c:12:15 ]
  }

Where the ADDri instruction has the correct location + inlining information attached to it. Looking at the line table produced, the ADDri instruction has it's location dropped, and it gets the line number from the RETL instruction. If that's expected and the correct behaviour for sparc, then we should alter the test, however if that ADDri is supposed to get the inlined line number then there's a bug somewhere else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95617