<div dir="ltr">Hi Aleksei,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 2 March 2016 at 14:42, Aleksei Sidorin via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Gabor,<br>
<br>
We still use a file-by-file approach so we don't build a full AST but merging ASTs of analyzed callees only where possible. We build a mapping showing what file contains required functions. Then, we analyze a project file-by-file. During analysis, we import this definition to our TU if we meet a call with a callee definition in another file,  and continue analysis as usually.<br>
<br>
This approach seems to work. It should get much better performance after implementation of summary serialization due to summary inter-TU reusage. We don't build a full project AST but this is not a memory bottleneck: a real bottleneck currently is function summaries.<br></blockquote><div><br></div><div>So basically this approach is functional right now on large scale projects and it is orthogonal to the summary based method you developed (so it can be used with inlining), but you are not satisfied with the performance (and I/O is not the bottleneck). Is that right? Did you make some benchmarks?<br><br></div><div>What happens when you meet a call with a callee definition in another file in a just imported definition? Do you import that definition as well? Don't you end up having almost all of the project AST in the memory this way?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Currently we're working on upstreaming our ASTImporter work. This work is slow enough because it requires massive test writing (ASTImporter lacks tests now). But we hope, it will become available for all clang users who needs it.<span><br></span></blockquote><div><br></div><div>That sounds awesome, thank you :)<br><br></div><div>Regards,<br></div><div>Gábor<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
Do you have some updates? I checked the repository, and there are python<br>
scripts indicating cross TU analysis support (and there were also some<br>
ASTImporter work). I was wondering what is the state of this? What is the<br>
approach you are using? Does that approach work, when the unified AST<br>
possibly not fit into the memory?<br>
<br>
<br>
</blockquote>
<br></span><span><font color="#888888">
-- <br>
Best regards,<br>
Aleksei Sidorin<br>
Software Engineer,<br>
IMSWL-IMCG, SRR, Samsung Electronics</font></span><div><div><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div></div>