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

[David Blaikie]

On Mon, Nov 25, 2013 at 2:04 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

> > -----Original Message-----
> > From: Eric Christopher [mailto:echristo at gmail.com]
> > Sent: Monday, November 25, 2013 1:33 PM
> > To: Sean Silva
> > Cc: David Blaikie; Robinson, Paul; cfe-dev at cs.uiuc.edu
> > Subject: Re: [cfe-dev] Optionally suppress debug info for inlined calls?
> >
> > On Mon, Nov 25, 2013 at 1:31 PM, Sean Silva <silvas at purdue.edu> wrote:
> > >
> > >
> > >
> > > On Mon, Nov 25, 2013 at 2:21 PM, David Blaikie <dblaikie at gmail.com>
> > wrote:
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Nov 25, 2013 at 11:18 AM, Robinson, Paul
> > >> <Paul_Robinson at playstation.sony.com> wrote:
> > >>>
> > >>> I have _already_ turned it off for my target,
> > >>
> > >>
> > >> Right, I got that - was just trying to understand if/why that was the
> > >> right choice.
> > >>
> > >>>
> > >>> per request from licensees who don't like seeing fake call frames
> > that
> > >>> don't reflect actual calls in the generated code.
> > >>
> > >>
> > >> Just tossing around ideas to accommodate your licensees/Clang users:
> > would
> > >> this make more sense as a feature of debuggers/stack trace tools,
> > etc? Are
> > >> there particular places where this shows up and confuses users?
> > >
> > >
> > > Aside from getter/setters like Paul mentioned, also SIMD vector types
> > (as
> > > you might expect, game engines are heavy users of SIMD vector types).
> > > Essentially every arithmetic operation becomes a function call, and
> > it's not
> > > out of the ordinary to have, say, 30+ arithmetic operations in a
> > single
> > > short function (each compiling down to a single instruction of machine
> > > code).
> > >
> >
> > __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.


> We'd like our game teams to spend their time on more productive
> tasks than adding attribute(nodebug) to every method in every
> header.


Fair point - this is where I was wondering if we could do a better job with
features in debuggers and/or debug info to appropriately describe such
trivial functions and have useful behavior for them in a debugger.

Dropping the information at such a coarse granularity as "all inline
functions" seems a bit, well, rough. 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.

Though unless we can find a /really/ strong signal that allows us to guess
with certainty that some functions just aren't worth having debug info,
ever, I'd probably look towards debugger features that make this guess at
debug time and thus can be overridden without recompiling/rebuilding if the
guess is wrong.


>  Plus we have an interest in continuing to support
> features that we have provided on previous platforms.


Certainly - but that's a burden for you right now. Once we add it as a
feature for Clang, it's a burden for all of us for a much longer timeframe,
perhaps. So you can see why we might want to ensure we're making the right
decision.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131125/0cf789d6/attachment.html>