[cfe-dev] [analyzer] Summary IPA thoughts +code
Aleksei Sidorin via cfe-dev
cfe-dev at lists.llvm.org
Wed Mar 2 07:04:42 PST 2016
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
> 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 :)
> 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>
IMSWL-IMCG, SRR, Samsung Electronics
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev