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

[David Blaikie]

On Wed, Nov 27, 2013 at 2:08 PM, Robinson, Paul
<Paul_Robinson at playstation.sony.com> wrote:
>> > > 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.

I'm not so sure that's the case - and realistically I suspect this
would have to be a debugger feature (perhaps powered by new/improved
information in the DWARF to help the debugger make the right choice)
so that it could be overridden when necessary.

I'm not sure such a heuristic exists, but it's something that seems
worth considering.

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

I'm not sure I follow what you mean by "compile-developer-friendly
abstraction" - whether you're referring to my using the LLVM codebase
as an example or you're describing my attitude, regardless of example.

I think LLVM isn't a very strange/uncommon example of C++ code as
regards to the inline function complexity.

And, yes, likely this would be better at the debugger feature than a
compiler feature - so it can be turned off/on/configured by the user.

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

OK - so what was their request? Just that they don't step into
"uninteresting" functions & you chose inline as the heuristic to use?

- David