<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Technically all these analyses can be conducted in source-based
    manner.<br>
    <br>
    And as John says, that'd have the advantage of being more
    predictable; we'd no longer have to investigate sudden changes in
    analysis results that are in fact caused by backend changes. We
    already are quite unpredictable with our analysis, with arbitrary
    things affecting arbitrary things, and that's ok, but it doesn't
    mean we should make it worse. In particular i'm worried for people
    who treat analyzer warnings as errors in their builds; for them any
    update in the compiler would now cause their build to fail, even if
    we didn't change anything in the static analyzer. (Well, for the
    same reason i generally don't recommend treating analyzer warnings
    as errors).<br>
    <br>
    So i believe that implementing as many of these analyses over the
    Clang CFG (or in many cases it might be over the AST as well) would
    be beneficial and should be done regardless of this experiment.
    Gabor, how much did you try that? Because i believe you should try
    that and compare the results, at least for some analyses that are
    easy to implement.<br>
    <br>
    The reason why the use of LLVM IR in the static analyzer gets really
    interesting is because there are already a huge lot of analyses
    already implemented over it and getting access to them "for free"
    (in terms of implementation cost) is fairly tempting. I think that's
    the only real reason; it's a pretty big reason though, because the
    amount of work we're saving us this way may be pretty large if we
    put a lot of those analyses to good use.<br>
    <br>
    <div class="moz-cite-prefix">On 14.08.2020 04:19, Gábor Márton
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH6rKyBqVcd2d3uN=XKEGEvj8ps35tCWQSKuDnq3A=Zd0ShK3g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">John, thank you for your reply. 
        <div><br>
        </div>
        <div>> Is this really the most reasonable way to get the
          information you want?</div>
        <div>Here is a list of information we would like to have access
          to (this is non-comprehensive, Artem could probably extend it)
          :<br>
        </div>
        <div>1) Is a function pure? </div>
        <div>2) Does a function read/write only the memory pointed to by
          its arguments?</div>
        <div>3) Does a calle make any copies of the pointer argument
          that outlive the callee itself?</div>
        <div>4) Value ranges.<br>
        </div>
        <div>5) Is a loop dead?</div>
        <div>6) Is a parameter or return pointer is dereferenceable?</div>
        <div><br>
        </div>
        <div>How could we use this information?</div>
        <div>With 1-3 we could make the analysis more precise by
          improving the over-approximation done by invalidation during
          conservative evaluation.</div>
        <div>Using the info from 1-4 we could create "summaries" for
          functions and we could skip the inlining based evaluation of
          them. This would be really beneficial in case of
          cross-translation-unit analysis where the inling stack can
          grow really deep. <br>
        </div>
        <div>With 5, we could skip the analysis of dead loops and thus
          could spare the budget for the symbolic execution in CSA.<br>
        </div>
        <div>By using 6, we could eliminate some false-positive reports,
          this way improving correctness.</div>
        <div><br>
          Some of the analyses that provide the needed information can
          be implemented properly only by using the SSA form. For
          example, value range propagation. We could do our own way of
          lowering to SSA, or our own implementation of alias analysis
          for the pureness info, but that would be repeating the work
          that had already been done and well tested in LLVM.<br>
        </div>
        <div><br>
        </div>
        <div>> It’s also pretty expensive.</div>
        <div>I completely agree that we should not pay for those
          optimization passes whose results we cannot use in the CSA. In
          the first version of the patch I used the whole O2 pipeline,
          but lately I updated it to use only those passes that are
          needed to get the pureness information (GlobalsAA and
          PostOrderFunctionAttrs).</div>
        <div>Also, static analysis is generally considered to be slower
          than compilation <span style="font-family:"Lucida
            Grande","Lucida Sans
            Unicode",Arial,Verdana,Helvetica,sans-serif">even with
            optimizations enabled. We even advertise this in our
            official webpage (<a href="https://clang-analyzer.llvm.org/"
              moz-do-not-send="true">here</a>). </span>And this
          extension will never be more expensive than a regular O2/O3
          compilation. So, this implies that a 2-4x slowdown of CSA
          could become a 3-5x slowdown, compared to an O2 compilation.
          In CTU mode, the analysis time is even slower currently, so
          the additional CodeGen would be less noticable. The slowdown
          may not be affordable for some clients, so users must
          explicitly require CodeGen in CSA via a command-line switch. I
          plan to provide precise results on open-source projects to
          measure the slowdown. On top of that, it would be interesting
          to see how many times can we get the desired information in
          the ratio of all functions (all call sites, all loops).</div>
        <div><br>
        </div>
        <div>Gabor.</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, Aug 14, 2020 at 6:46
          AM John McCall <<a href="mailto:rjmccall@apple.com"
            moz-do-not-send="true">rjmccall@apple.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">On
          13 Aug 2020, at 10:15, Gábor Márton wrote:<br>
          > Artem, John,<br>
          ><br>
          > How should we proceed with this?<br>
          ><br>
          > John, you mention in the patch that this is a huge
          architectural <br>
          > change.<br>
          > Could you please elaborate? Are you concerned about the
          additional <br>
          > libs<br>
          > that are being linked to the static analyzer libraries?
          The clang <br>
          > binary is<br>
          > already dependent on LLVM libs and on the CodeGen and CSA
          is builtin <br>
          > to the<br>
          > clang binary. Are you concerned about having a
          MultiplexConsumer as an<br>
          > ASTConsumer? ... I am open to any suggestions, but I need
          more input<br>
          > from you.<br>
          <br>
          Well, it’s adding a major new dependency to the static
          analyzer and a <br>
          major new client to IRGen.  In both cases, the
          dependency/client happens <br>
          to be another part of Clang, but still, it seems like a huge
          deal for <br>
          static analysis to start depending on potentially arbitrary
          details of <br>
          code generation and LLVM optimization.  It’s also pretty
          expensive.  <br>
          Is this really the most reasonable way to get the information
          you want?<br>
          <br>
          John.<br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>