<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Dec 12, 2012, at 6:00 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:</div><blockquote type="cite"><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><div style="">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 style=""><br></div><div style="">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 style=""><br></div><div style="">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 style=""><br></div><div style="">
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 style=""><br></div><div style="">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 style=""><br></div><div style="">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>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><br></div><div>John.</div></body></html>