<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 25, 2013 at 2:04 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> -----Original Message-----<br>
> From: Eric Christopher [mailto:<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>]<br>
> Sent: Monday, November 25, 2013 1:33 PM<br>
> To: Sean Silva<br>
> Cc: David Blaikie; Robinson, Paul; <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> Subject: Re: [cfe-dev] Optionally suppress debug info for inlined calls?<br>
><br>
</div><div><div class="h5">> On Mon, Nov 25, 2013 at 1:31 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Mon, Nov 25, 2013 at 2:21 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
> wrote:<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> On Mon, Nov 25, 2013 at 11:18 AM, Robinson, Paul<br>
> >> <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>> wrote:<br>
> >>><br>
> >>> I have _already_ turned it off for my target,<br>
> >><br>
> >><br>
> >> Right, I got that - was just trying to understand if/why that was the<br>
> >> right choice.<br>
> >><br>
> >>><br>
> >>> per request from licensees who don't like seeing fake call frames<br>
> that<br>
> >>> don't reflect actual calls in the generated code.<br>
> >><br>
> >><br>
> >> Just tossing around ideas to accommodate your licensees/Clang users:<br>
> would<br>
> >> this make more sense as a feature of debuggers/stack trace tools,<br>
> etc? Are<br>
> >> there particular places where this shows up and confuses users?<br>
> ><br>
> ><br>
> > Aside from getter/setters like Paul mentioned, also SIMD vector types<br>
> (as<br>
> > you might expect, game engines are heavy users of SIMD vector types).<br>
> > Essentially every arithmetic operation becomes a function call, and<br>
> it's not<br>
> > out of the ordinary to have, say, 30+ arithmetic operations in a<br>
> single<br>
> > short function (each compiling down to a single instruction of machine<br>
> > code).<br>
> ><br>
><br>
> __attribute__((__always_inline__, __nodebug__))?<br>
<br>
</div></div>In fact the intrinsics, and to a significant extent some<br>
vector math libraries, do that.  But, it's pretty tedious.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We'd like our game teams to spend their time on more productive<br>
tasks than adding attribute(nodebug) to every method in every<br>
header. </blockquote><div><br></div><div>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.<br>
<br>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.<br>
<br>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Plus we have an interest in continuing to support<br>
features that we have provided on previous platforms.</blockquote><div><br>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.<br>
<br>- David </div></div></div></div>