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

[Robinson, Paul]

> > > __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; so let's not
get hung up on attributes.  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.

> 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."  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.)

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

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]

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.
(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.
(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.

--paulr