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

[Robinson, Paul]

> -----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.
We'd like our game teams to spend their time on more productive
tasks than adding attribute(nodebug) to every method in every
header.  Plus we have an interest in continuing to support
features that we have provided on previous platforms.
--paulr

> 
> -eric
> 
> > -- Sean Silva
> >
> >>
> >>
> >>>
> >>> The size win doesn't hurt but is secondary.
> >>>
> >>>
> >>>
> >>> The problem now is that not everybody likes it that way, and so I
> want to
> >>> make it optional, and I'd rather have the feature upstream than keep
> it
> >>> private.
> >>>
> >>>
> >>>
> >>> (While I'm not ready to file any bugs, I did notice some strangeness
> in
> >>> the low/hi_pc ranges for some inlined ctors; the ranges mostly or
> completely
> >>> overlapped, which didn't seem right but I didn't look into it.
> That's not
> >>> my focus right now.)
> >>>
> >>> --paulr
> >>>
> >>>
> >>>
> >>> From: David Blaikie [mailto:dblaikie at gmail.com]
> >>> Sent: Monday, November 25, 2013 11:02 AM
> >>> To: Robinson, Paul
> >>> Cc: cfe-dev at cs.uiuc.edu
> >>> Subject: Re: [cfe-dev] Optionally suppress debug info for inlined
> calls?
> >>>
> >>>
> >>>
> >>> Why do you want to turn this off?
> >>>
> >>> Is it buggy? Could we fix it?
> >>> Is it too big? Could we reduce size in ways that are strict-wins
> instead?
> >>>
> >>>
> >>>
> >>> On Mon, Nov 25, 2013 at 10:57 AM, Robinson, Paul
> >>> <Paul_Robinson at playstation.sony.com> wrote:
> >>>
> >>> In general on our platform we don't want debug info for inlined
> calls
> >>> (messy, awkward things) but some people still like to see them.
> >>> Currently
> >>> we turn them off unconditionally in our private tree, but we'd like
> to
> >>> put
> >>> this under command-line control and send it upstream.  Does anyone
> mind
> >>> if
> >>> I do this?  I was thinking a command-line option along the lines of
> >>>       -g[no-]inlined-scopes
> >>> We'd default to No on our target, Yes everywhere else.  If you turn
> these
> >>> off, you don't get DW_TAG_inlined_scope, and the source location
> info for
> >>> all the inlined code becomes the call site (single-stepping would
> act
> >>> like
> >>> it's an external call that you step over).
> >>>
> >>> Thanks,
> >>> --paulr
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cfe-dev mailing list
> >>> cfe-dev at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>>
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >