<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Yup, max-times-inline-large controls how many times do functions
that have (min-cfg-size-treat-functions-as-large) or more Control
Flow Graph blocks are "inlined" during analysis when called from
other functions. This doesn't apply to functions from which the
analysis *starts* (you can list them via
-analyzer-display-progress).<br>
<br>
But note that if a function was inlined, then it usually *won't* be
re-analyzed as a top-level function. This heuristic is based on the
assumption that the reliability of warnings found by analyzing the
function as a top-level function is usually much lower than that of
warnings found within an inlined function, because when inlining,
you have more context on how the function is actually used in the
program.<br>
<br>
Yup, the complexity value that max-symbol-complexity limits is
roughly as long as the "length" of the most complicated symbolic
expression. Every atomic symbol (SymbolData) has complexity of 1, a
constant has complexity 0, and every operation also adds 1 to the
complexity of its operands, unless both operands are non-constants
(but this last part seems to be an accidental omission). Anyway, the
point is, when the symbolic expression becomes too long, the Static
Analyzer prefers to collapse it to UnknownVal in order to avoid
performance problems. This is usually not terrible because when a
piece of code produces terribly complicated symbolic expressions,
the user is more likely to forgive us for not understanding it
perfectly :)<br>
<br>
Generally, these -analyzer-config tweaks are simply a way to avoid
magic constants in the code. They help when trying to find the best
value for the magic constant, but they aren't recommended for
everyday use. But if it suddenly turns out that some non-standard
-analyzer-config values make the Static Analyzer perform
significantly better on your code, please let us know :)<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 3/7/19 7:47 PM, Sulekha Kulkarni via
cfe-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKNeUtkzvqJueKZ627u0Rr5dB-0FnR6=Lk0NKOwrutb10pU4Ow@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I am a fairly new entrant to Clang SA. I wanted to
confirm the behavior of the following two analyzer-config
options:</div>
<div><br>
</div>
<div>max-times-inline-large : When CSA is analyzing a
compilation unit, at most max-times-inline-large "large"
functions will be inlined during the analysis of the
entire CU. In particular, it is not applied per-top-level
function analyzed. Is this correct? </div>
<div>A test I did: Suppose a CU t.c contains a function
foo() that has a null dereference, and several other
functions. The command "<i>clang -cc1 -analyze
-analyzer-checker=core.NullDereference t.c
-analyze-function=foo</i>" detects the null deref bug
while the command "<i>clang -cc1 -analyze
-analyzer-checker=core.NullDereference t.c</i>" does
not. When I increased the max-times-inline-large value,
running CSA on the entire t.c did detect the null deref
bug.</div>
<div><br>
</div>
<div>max-symbol-complexity=35 : What is the number 35
counting? Is it (approximately) the number of operators in
a symbolic expression?</div>
<div><br>
</div>
<div>I'll really appreciate any clarification on these
points.</div>
<div><br>
</div>
<div>Thanks in advance,</div>
<div>Sulekha</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>