[cfe-dev] [analyzer] Summary IPA thoughts +code

[Aleksei Sidorin via cfe-dev]

02.03.2016 17:08, Gábor Horváth пишет:
> Hi Aleksei,
>
> On 2 March 2016 at 14:42, Aleksei Sidorin via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     Hello Gabor,
>
>     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.
>
>     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.
>
>
> 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?
>

Yes, you're right. We made some benchmarks  on Android source code and 
found it slower than we expected. I/O may be a reason because we use AST 
dumps that require some disk I/O. But it works. And yes, it is 
independent from IPA method. We didn't do any I/O optimization yet, 
because we want to make it stable first.
> 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?
That's possible, in theory. But in practice, we don't import too many 
declarations before node limit is reached :)
>
>
>     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.
>
>
> That sounds awesome, thank you :)
>
> Regards,
> Gábor
>
>
>         Hi!
>
>         Do you have some updates? I checked the repository, and there
>         are python
>         scripts indicating cross TU analysis support (and there were
>         also some
>         ASTImporter work). I was wondering what is the state of this?
>         What is the
>         approach you are using? Does that approach work, when the
>         unified AST
>         possibly not fit into the memory?
>
>
>
>     -- 
>     Best regards,
>     Aleksei Sidorin
>     Software Engineer,
>     IMSWL-IMCG, SRR, Samsung Electronics
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>


-- 
Best regards,
Aleksei Sidorin
Software Engineer,
IMSWL-IMCG, SRR, Samsung Electronics

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160302/22ca6c12/attachment.html>