<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>