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

[Robinson, Paul]

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

I don't doubt we could come up with some sort of heuristic that would
make sense to us as compiler developers (e.g.: fewer than X instructions
with at most 1 conditional branch).

I am doubtful, however, that any such heuristic will conform to what
a colleague once called "the principle of least surprise."  That is,
it will not be easy to explain to users how that heuristic influences 
whether they can step into a "trivial" function.  Having the debugger
step into or over function calls, based on mysterious compiler-internal
criteria rather than something the user can readily discern, is not
such a good experience.

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

I offer that heuristic because it is easy to explain, easy to remember,
and easy for users to apply when eyeballing their own code.  Not because
it conforms to some compiler-developer-friendly abstraction of the
dividing line between "trivial" and "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).

yes, the criterion of "marked inline" came from them, not me.
--paulr

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