<div dir="ltr">Thanks, Artem, for the detailed clarifications - it was very helpful!<div><br><div>Sulekha</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019 at 8:06 PM Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div 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="gmail-m_9191426422614118930moz-cite-prefix">On 3/7/19 7:47 PM, Sulekha Kulkarni via
      cfe-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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="gmail-m_9191426422614118930mimeAttachmentHeader"></fieldset>
      <pre class="gmail-m_9191426422614118930moz-quote-pre">_______________________________________________
cfe-dev mailing list
<a class="gmail-m_9191426422614118930moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a class="gmail-m_9191426422614118930moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div>