[cfe-dev] How to configurate the Clang Static Analyzer to tuning its IPA?

[Aleksei Sidorin]

Hello Arthur,

There are some options that may be set using '-analyzer-config' option. 
Example: -analyzer-config max-nodes=100000
1. max-nodes - maximal number of nodes of exploded graph that may be 
analyzed for a top-level function. That does not limit number of nodes 
that may be enqueued to worklist. 150000 by default.
2. mode - user analysis modes. Values: 'shallow' (set default max-nodes 
to 75000) and 'deep' (default). Seems like you already tried to set it 
somehow.
3. ipa-always-inline-size - set limit number of CFGBlocks in functions 
that analyzer thinks as "small".
There are some other options. You may use debug.ConfigDumper checker to 
view your default analysis options (or options you set). You can take a 
look on test/Analysis/analyzer-config.c of clang source tree 
(https://github.com/llvm-mirror/clang/blob/master/test/Analysis/analyzer-config.cpp) 
to see them and their default values. You can also take a look on 
AnalyzerOptions class of clang 
(http://clang.llvm.org/doxygen/classclang_1_1AnalyzerOptions.html).

But could you clarify your question?

1. IPA mode is not IPA_NotSet by default. IPA_NotSet is only an internal 
flag pointing user didn't specify any option and some default value 
should be used. You can take a look into AnalyzerOptions::getIPAMode() 
method. If IPA options were not specified, CSA uses 
IPAK_DynamicDispatchBifurcate option by default so your changes in 
IPA_Mode should not change anything (or make even worse).

2. If you attach your file, we can understand more things about your case.

3. There is no so much for memory limit but for time limit. CSA doesn't 
use summary approach currently, it inlines a function or loop iteration 
every time it is met. It can lead to slow analysis so CSA limits loop 
inlining and function inlining as well as number of ExplodedNodes 
analyzed to finish analysis in a reasonable time. Number of nodes 
analyzed per function is limited but number of nodes enqueued is not so 
there may be interesting cases. Take  a look on 
external/qemu/target-mips/translate.c file from Android source tree: its 
analysis with CSA made 96 Gb server swapping. But most files you'll 
analyze will not consume over 300 Mb with default analyzer options.

4. The fact that function evaluation is happens twice is strange. How 
did you check this? Maybe it was analyzed multiple time as a separate 
function and as a callee of other functions? Again, attaching a test 
case may help.

5. Are there problems with analysis correctness that forced you to find 
additional options? Can you explain what do you want to get with these 
options?

> Hi all,
>
> I find that Clang Static Analyzer can support Inter-Procedural Analysis
> (IPA) in one single TranslationUnit. But I was confused by its IPA's 
> result
> for my testcase (C program) with the default arguments and 
> configuration of
> Static Analyzer. For example, one function was called again in the middle
> of its evaluation. And the function itself is not a recursive function.
> My testcase contains three functions in one single file. And there are 
> some
> loops in two of functions. There is no any recursive function in my
> testcase.
>
> I guess the default analysis-related arguments/configuration will 
> guarantee
> that the Static Analyzer will archieve precise analysis results, in the
> meanwhile it will also guarantee an appropriate memory space utilization.
>
> However, for my testcase, I feel that the default configuration spent too
> much attention on the memory aspect, so that it scarificed the 
> integrity of
> the analysis. In this way, the result of the IPA evaluation confused 
> me. My
> test machine has 32GB RAM. So for the primary tests current, I paid more
> attention on the correctness of my checker than the low memory 
> utilization.
> So I began to search the arguments of Static Analyzer, which may/will 
> limit
> the scale of the evaluation. I tuned the values of analyzer_max_loop and
> analyzer_inline_max_stack_depth with bigger number values. And I also set
> UserMode from UMK_NotSet to UMK_Deep, and set IPAMode from IPAK_NotSet to
> IPAK_Inlining. However, it seems that it doesn't work and the results 
> still
> cunfused me.
>
> Now I'm wondering that whether there is any other argument that will
> limit/modify the function's evaluation according to scale or the 
> number of
> the ExplodedNodes of the function.
>
> What's more, are there any other arguments I can tune, which can
> loose/relax the limitations of the Static Analyzer, so that it can 
> archieve
> more precise analysis results, in spite of the fact that it may
> protentially lead to more memory occupation? If there are, where and what
> are they?
>
> Thanks a lot.
>
-- 
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/20140630/3e36e82d/attachment.html>