<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr">On Wed, Dec 12, 2012 at 11:45 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><div>On Dec 12, 2012, at 6:00 AM, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:</div>
</div><div><div class="h5"><blockquote type="cite"><div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div dir="ltr"><div>while doing some parsing speed investigation I noted that a lot of diagnostics stuff is in the very hot path for parsing time. One thing that fell out of that is Benjamin's recent patch that speeds up getting the diagnostic info. But, there's more to be gotten - with a simple cache for the diagnotic classes, I was able to get another 1.5% parsing speedup (benchmarked over all google code).</div>

<div><br></div><div>Unfortunately the patch in its current state is not thread safe; the obvious solution to that problem would be to generate the diagnostic class table statically instead of writing to a cache at runtime.</div>

<div><br></div><div>This turns out to be surprisingly hard though - the diagnostic id start values are defined in an enum, while the actual diagnostics come from the .td files.</div><div><br></div><div>
A first idea was that we might define the start values inside the .td files, and create the enum from that, instead of the other way around.</div><div><br></div><div>That led to the question posed by Dmitri on irc why there are start ranges in the first place - we could instead tablegen all diagnostics at once and let the tablegen take care of generating the appropriate enum values for the start of certain ranges.</div>

<div><br></div><div>So if anybody has better ideas for how to solve the lookup problem, or knows why the diagnostic ids have fixed start values, I'd be very interested to learn more about it :)</div></div></div></blockquote>
<br></div></div></div><div>The purpose of the fixed starting values is just compile-time efficiency: we'd like to be able to add/remove diagnostics (generally in one part of clang) without requiring a full recompile.  As long as your scheme still allows this in most cases — maybe tblgen gets re-run for all diagnostics whenever any of them change, but tblgen rounds up to the next multiple of 50 between ranges so that adding a diagnostic in one range doesn't usually force a full recompile — I think we're fine.</div>
</div></blockquote><div><br></div><div style>Of the Diagnostic*Kinds.td files the only one that gets updated fairly regularly (every 1-2 days) is DiagnosticSemaKinds.td. Can't we just put it last, and save the hassle of putting holes into the generated lookup tables? (The next highest frequent change is ~4-5 times per month; in that time frame a full rebuild is in order anyway).</div>
<div style><br></div><div style>Cheers,</div><div style>/Manuel</div></div></div></div></div>