<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 25, 2013 at 6:00 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im">On Mon, Nov 25, 2013 at 2:16 PM, "C. Bergström" <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 11/26/13 05:04 AM, Robinson, Paul wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>

</blockquote></div></blockquote><div><br></div></div><div>Are these class methods?  Can we support slapping attribute(nodebug) on the whole class definition maybe?</div></div></div></div></blockquote><div><br></div><div>
That might alleviate things a bit.</div><div><br></div><div>One point of concern even for that is that these SIMD classes can be (and are) in the headers of a (generally proprietary) library that you are using (proprietary, but there's still dozens of KLOC of templates in headers that you import into your project, besides the binary lib). In that case, the user is suddenly in really uncomfortable territory of modifying external headers, which I think is not something you want to tell users is "the solution" (also, as just a user of those libraries, they likely don't understand the logic behind their macros and how they are meant to be used to be able to confidently know which ones to tweak to add various magic attributes; or perhaps changing those headers might not even be allowed by the agreement).</div>
<div><br></div><div>Ultimately Paul et al. are the ones that have the users knocking on their door and have the clearest idea of what the use case looks like. I'm mostly working from memory from code I've looked at.</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>It really does seem desirable to get this to the state where little big leaf functions have debug info but little math overloads are elided.</div>
</div></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>