<p dir="ltr">We actually went from a more expression templatey to a less expression templatey design. Sam has worked on making clang tidy use cases faster. I expect in the end the right thing is to do less duplicate work which I think we will be able to do with modules.<br>
</p>
<br><div class="gmail_quote">On Tue, Apr 7, 2015, 3:31 PM Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Although I'm mostly an armchair spectator right now w.r.t. clang tooling stuff, I think that use cases like clang-query and in general the dynamic AST matchers suggests that expression templates aren't a very good solution because they will require reimplementing things from scratch for the "dynamic" case.<div><br></div><div>Regardless, I don't think that the primary bottleneck is not doing enough at compile time (of the matchers). Rather we aren't effectively indexing the underlying data set we are trying to query (right now, we're more like grep and less like google). Indexing starts paying off once you have to do multiple queries* and can amortize the indexing cost across all those queries. I think most uses for clang-tidy have enough ast matching in them for indexing to pay off. Note that indexing doesn't have to return results immediately; it just needs to prune the search space enough to pay off (a good example is using a trigram index to prune the search space for regexp matching <a href="http://swtch.com/~rsc/regexp/regexp4.html" target="_blank">http://swtch.com/~rsc/regexp/regexp4.html</a>).</div><div><br></div><div>* "multiple" here also scales numerically with the number of TU's. An index can avoid visiting certain TU's at all in many cases.</div><div><br></div><div>-- Sean Silva</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 7, 2015 at 2:01 PM, Richard <span dir="ltr"><<a href="mailto:legalize@xmission.com" target="_blank">legalize@xmission.com</a>></span> wrote:<br></div></div><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">OCLint, a lint checker using clang tooling, says:<br>
<<a href="http://docs.oclint.org/en/dev/internals/rules.html" target="_blank">http://docs.oclint.org/en/dev/internals/rules.html</a>><br>
<br>
    "Using AST matchers has more restrictions than AST visitor, and it<br>
    takes much longer time in analysis, this could lower the<br>
    performance of the tool. So, we always have to consider the<br>
    trade-off, and choose wisely."<br>
<br>
It seems that AST matchers, while convenient, are not the best<br>
performing option for processing source files.  I've done some simplistic<br>
measurements on clang-tidy and found that the majority of the execution<br>
time is spent in the matchers.  I believe this is the result of the<br>
matchers building runtime structures to match nodes.<br>
<br>
Has anyone investigated using the technique of expression templates to<br>
get the convenience of an AST matching domain-specific language (DSL)<br>
with the runtime efficiency of an AST visitor?<br>
<br>
If we were to pursue such a direction, would it be possible to use an<br>
expression template library like those in Boost for the implementation?<br>
I don't see any existing use of Boost in the LLVM/clang code base, so<br>
I infer that there is some avoidance of Boost for whatever reason.  I<br>
haven't done any expression template coding beyond using existing<br>
expression template based libraries like Boost.Spirit.  I have no idea<br>
what it would take to create an expression template based AST matcher<br>
DSL for clang, but it seems like it would be worthwhile as it would<br>
speed up all the tools that want to use the AST matcher style<br>
interface.<br>
<br>
Does anyone have any thoughts about this?  Pehraps Manuel Klimek?<br>
</blockquote></div></div><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"><span><font color="#888888">--<br>
"The Direct3D Graphics Pipeline" free book <<a href="http://tinyurl.com/d3d-pipeline" target="_blank">http://tinyurl.com/d3d-pipeline</a>><br>
     The Computer Graphics Museum <<a href="http://ComputerGraphicsMuseum.org" target="_blank">http://ComputerGraphicsMuseum.org</a>><br>
         The Terminals Wiki <<a href="http://terminals.classiccmp.org" target="_blank">http://terminals.classiccmp.org</a>><br>
  Legalize Adulthood! (my blog) <<a href="http://LegalizeAdulthood.wordpress.com" target="_blank">http://LegalizeAdulthood.wordpress.com</a>><br></font></span></blockquote></div></div><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"><span><font color="#888888">
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">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>
</font></span></blockquote></div><br></div>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">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/<u></u>mailman/listinfo/cfe-dev</a><br>
</blockquote></div>