llvm dev - Apr 2021 - llvm-dwarfdump stats for inlined functions

Hi,

As discussed on the https://reviews.llvm.org/D101025, we have noticed that there
are two different stat categories for inlined functions when using
`llvm-dwarfdump –statistics`:
# inlined functions
# inlined functions with abstract origin
and it was introduced after the D58849. We were wondering if there is a
particular motivation of doing so.

Having an inlined_subroutine DIE with no abstract_origin attribute does not have
so many benefits, so it might be better if we have an assertion/error (e.g., in
the AsmPrinter) when we face such situation (or just to avoid dumping it into
the final DWARF).

Any thoughts?

Best regards,
Djordje

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210428/07130503/attachment.html>

Pedantically, DW_AT_abstract_origin is not required on a
DW_TAG_inlined_subroutine; the DWARF spec says a concrete instance
"may" omit attributes not specific to that instance, in which case
there will be an abstract origin that will have those attributes.  It then goes
on to point out that declaration coordinates (DW_AT_decl_[file,line,column]) are
for the declaration, not the inlining site, which makes them good candidates for
hoisting to the abstract origin.

That is, DW_AT_abstract_origin is a way to optimize for size; it isn't
mandatory.  So, I think llvm-dwarfdump is correct to allow it.  I might prefer
that "inlined functions without abstract origin" be what's called
out separately, rather than the "with" case, as the
"without" cases represent a likely opportunity for size reduction.

I don't *think* we ever emit an inlined_subroutine without an abstract
origin?  If we want to make it an assertion on the emission side, that would be
fine.  In fact, now that we omit DW_TAG_formal_parameter where the parameter has
been optimized away, it's probably a good idea to have an assertion like
that.
--paulr

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Djordje
Todorovic via llvm-dev
Sent: Wednesday, April 28, 2021 7:12 AM
To: llvm-dev <llvm-dev at lists.llvm.org>
Cc: asowda at cisco.com
Subject: [llvm-dev] llvm-dwarfdump stats for inlined functions

Hi,

As discussed on the
https://reviews.llvm.org/D101025<https://urldefense.com/v3/__https:/reviews.llvm.org/D101025__;!!JmoZiZGBv3RvKRSx!p1JI3vREt1U9y0e7eU5KzIYOZy_bS-TM7CS1N8x6VtUXLtdwkALSba9mVadBYExR-Q$>,
we have noticed that there are two different stat categories for inlined
functions when using `llvm-dwarfdump -statistics`:
# inlined functions
# inlined functions with abstract origin
and it was introduced after the D58849. We were wondering if there is a
particular motivation of doing so.

Having an inlined_subroutine DIE with no abstract_origin attribute does not have
so many benefits, so it might be better if we have an assertion/error (e.g., in
the AsmPrinter) when we face such situation (or just to avoid dumping it into
the final DWARF).

Any thoughts?

Best regards,
Djordje

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210428/e4bb7d17/attachment.html>

On Wed, Apr 28, 2021 at 4:11 AM Djordje Todorovic <
Djordje.Todorovic at syrmia.com> wrote:
> Hi,
>
>
>
> As discussed on the https://reviews.llvm.org/D101025, we have noticed
> that there are two different stat categories for inlined functions when
> using `llvm-dwarfdump –statistics`:
>
> # inlined functions
>
> # inlined functions with abstract origin
>
> and it was introduced after the *D58849. *We were wondering if there is a
> particular motivation of doing so.
>
>
>
When I wrote D58849 I wasn't sure if all the inlined functions would have
abstract origins or not; that was one of the things I wanted to check on.

-- Caroline
cmtice at google.com

> Having an inlined_subroutine DIE with no abstract_origin attribute does
> not have so many benefits, so it might be better if we have an
> assertion/error (e.g., in the AsmPrinter) when we face such situation (or
> just to avoid dumping it into the final DWARF).
>
>
>
> Any thoughts?
>
>
>
> Best regards,
>
> Djordje
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210428/df10ecdd/attachment.html>