[cfe-dev] Optionally suppress debug info for inlined calls?

[David Blaikie]

On Mon, Nov 25, 2013 at 4:28 PM, Robinson, Paul
<Paul_Robinson at playstation.sony.com> wrote:
>
> > > > __attribute__((__always_inline__, __nodebug__))?
> > > In fact the intrinsics, and to a significant extent some
> > > vector math libraries, do that.  But, it's pretty tedious.
> >
> > Most people wrap these things in macros anyway, so it wouldn't seem
> > too bad to add nodebug to whatever macro stamps out always_inline.
>
> There are two other ways to mark something as to-be-inlined and
> they basically never have convenient macros attached;

I assume you're referring to 1) implicit-inline when member functions
are defined inline and 2) explicit use of the C++ 'inline' keyword?

> so let's not get hung up on attributes.

Sure

> I should remind you that my use case is -O2 -g not -O0 -g.
>
> > Dropping the information at such a coarse granularity as "all inline
> > functions" seems a bit, well, rough.
>
> No argument there.  Note that it isn't actually what our licensees
> asked for; it's what was low-cost to provide. Something better is okay.
> I am trying to head in that direction, however badly I am able to
> express that.

OK - that's somewhat of what I'm trying to discuss. It /seems/ like
your user requests aren't actually unique to your userbase. They seem
like common things anyone using a debugger might like - not to step
into/out of trivial functions.

So I'd like to think about whether there's a good, general,
on-by-default behavior we can use here.

> > If we could find a good heuristic
> > for "trivial inline functions" (maybe a function with a single setter
> > or return) and use that as our signal for "don't bother emitting debug
> > info for this" maybe that would be good. That would still provide the
> > size wins with the benefit that it might be beneficial to a broader
> > range of users.
>
> How about "any indication in the source that the programmer wanted it
> inlined."

I don't think that's sufficient - looking at Clang and LLVM there are
a variety of header-defined functions that are sufficiently
non-trivial as to be interesting to step through. Though perhaps, if
it were a debugger-feature, it would be sufficient to make that the
default and a debugger would have some feature to allow a user to
override it. My suspicion is that the debugger might need to do more
work to make a better decision there, though. But I'm not sure the
compiler can really give much more info - it'd essentially be up to
the debugger to examine a function, perhaps, and decide whether it was
"interesting".

>  That is: (i) method defined inside the class declaration;
> (ii) 'inline' keyword; (iii) an attribute that means "inline this."
> All of these are indications that the programmer wanted the function
> inlined, and if the programmer then builds the program using the
> proposed -gno-inlined-scopes feature, it should not be shocking to
> anyone that these inlined functions don't have debug info.  (Sorry to
> be proposing something that isn't shocking; it's all I got.)

Right - what I'm suggesting is that there is an underlying
feature/usability desire that should be on by default and I'm trying
to think/talk through how we might provide a better experience to all
our users by default, rather than with an explicit switch. (and while
some of your users explicitly requested this behavior, some didn't -
so they're not all going to be in the "the programmer explicitly
turned on this switch, of course they got that behavior" - they won't
know the switch is on, so the behavior may catch them by surprise)

> This is what our licensees actually asked for and I am not averse to
> giving it to them. :-)

They asked for a switch powered by inline hints? Fair enough - though,
again, I'm interested in seeing whether we can design a feature better
than our customer requests that addresses their underlying issue (&
perhaps that of others who haven't even asked for anything yet).

> I admit that it's not what we currently give them.  This makes me sad.
> But there is a path of progress that is perhaps clear only to me:
> (0) all scopes are emitted
>     [this is what is public today]
> (1) on my target, all actually-inlined scopes are always suppressed
>     [this is what I have today]
> (2) give all targets control over whether all actually-inlined scopes
>     are suppressed, using -g[no-]inlined-scopes
>     [this is the stage I'm proposing now]
> (3) make DW_AT_inline tell the actual truth about inlined functions,
>     i.e. the <declared-inline?, actually-inlined?> tuple
>     [improved DWARF conformance, woo-hoo!]
> (4) have -gno-inlined-scopes suppress only those scopes with a tuple
>     <declared=yes, actually-inlined=yes>
>     [what my users actually asked for]

This still isn't necessarily the end state I see as optimal. It sounds
like this isn't something users should have to enable/disable in their
build, but should be a debugger feature if possible.

> Now what's the debugging-experience benefit to all these stages?
> (0) Being our starting point, there's no benefit. :-)
> (1) My licensees don't bounce in and out of inlined functions.
>     Sadly this includes functions inlined heuristically, rather than
>     just the functions they asked to have inlined, so it's not optimal.
>     Also: Debug info ~25% smaller.

I'd like to see those numbers - but also I'd generally like to
approach debug info size as a separate yet equally important goal. One
in which we know how small is "small enough" (or what we're willing to
trade off in the size/fidelity space - which might still end up
motivating such a flag, but I'd find it unfortunate if it did) and
then set about trying to make debug info that small. There's still a
fair amount of general size improvements that I think can be made to
LLVM's DWARF output that I haven't had time/priority to pursue.

> (2) Anybody who asks, can get the debug-info size benefit.  Most people
>     who use -O0 -g will see a smaller benefit because only always_inline
>     functions are affected. Size benefit (and debugging-experience cost)
>     tracks optimization level.
>     My licensees can see inlined frames, if they want.
> (3) If and only if you have a debugger able to interpret the
>     DW_AT_inline attribute in all its glory, and willing to give you
>     control over what inlined frames you want to see, then you can start
>     having an improved debugging experience. But getting to this point
>     without the compiler leading the way is really a non-starter.

Certainly - fixing the inline attribute to have better fidelity seems
like general goodness. There's no space tradeoff - we already emit the
attribute, just without the right value.

> (4) An improved experience over (1)/(2) because heuristically-inlined
>     frames are back, without needing the spiffed-up debugger from (3).
>     Size benefit is less than (1), hard to know by how much.
>
> Possibly the path I see isn't so great and there's something better to do.
> Which possibly includes going away until (3) happens, but I'd obviously
> rather provide interim stages that I think are beneficial to everyone.
> If I'm wrong about that, well, okay.

Equally I'm just one voice - I don't speak for the user or the project
anymore than anyone else. I don't have a good sense about where the
best thing for LLVM is to have a stop-gap solution versus an out of
tree solution, versus waiting for the "perfect" long-term solution.
I'm just trying to understand the landscape here a bit better - what
the needs and alternatives are, what the perfect future looks like (if
there is one), how we get there, what tradeoffs we might be willing to
make along the way. Who's going to drive us towards that future and
how long will it take (how long will we live with interim solutions).

It's not uncommon in the project that we say "that solution that would
work for one contributor just isn't general purpose enough for the
project - if they want that functionality upstream, it should be done
in <this general way>" - we all have had features that hit this
situation and have paid the cost to do more general work to get
something upstreamable. I'm not saying that's

Thanks for helping explain the issues/options,

- David