<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The judgment of "how much slower is too much slower" is pretty
subjective, and depends on the project. Increasing a project's
build from 30 seconds to 5 minutes is probably too much for that
project. Increasing a project's build from 45 minutes to 55 minutes
is probably fine though.<br>
<br>
Adding a flag to a build is also a much lower barrier to entry to
get started. There are a lot of build systems out there, and
scan-build and compilation databases only work easily with a few of
those systems. Adding a build flag is pretty easy on every build
system that I've ever worked with.<br>
<br>
If the work is done right, then the combined compile+analyze
execution could be faster than a compile action followed by an
analyze action. If you're willing to give up "#ifndef
__clang_analyzer__", then the AST from the compile can be reused by
the analyzer. Even if you aren't willing to give up that feature,
doing a compile of a file immediately followed by an analysis of the
same file is probably going to be faster than doing all the compiles
then all the analyzes due to disk caching effects.<br>
<br>
<div class="moz-cite-prefix">On 2/2/2016 10:23 AM, David Blaikie
wrote:<br>
</div>
<blockquote
cite="mid:CAENS6Eu-2WDA=f6qre94bQKv3paQsfMd6Krs6OF+z0OGXPwPag@mail.gmail.com"
type="cite">
<div dir="ltr">Another possible (not mutually exclusive) extension
point to add static analysis into would be through the Tooling
interface and compilation databases - this would allow just the
analysis to be run, without making it part of a build (no one
would make static analysis part of an interactive build, it's
too slow, right? the only reason it was integrated into the
build with scan-build was because it was the best way to
discover the build commands - but the Tooling/Compilation
Database system allows us to separate build discovery from tool
execution)</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 2, 2016 at 6:19 AM, Craig,
Ben via cfe-dev <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> I'm all for this
idea. There is precedent for this in other tools (Visual
Studio's /analyze). I think it also greatly reduces the
need for build interposition via scan-build.<br>
<br>
I would ask that you think carefully about the output
format of the detailed analysis for -enable-analyze-pass.
If people are using -enable-analyze-pass on most of their
builds, then plist and html reports are likely to go
unread for the most part. Consider making "no detailed
analysis" an option for -enable-analyze-pass to help with
these use cases.
<div>
<div class="h5"><br>
<br>
<div>On 1/29/2016 9:04 PM, <Alexander G. Riccio>
via cfe-dev wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">
<div>As mentioned by myself, Aaron Ballman, and
Philip Reames, in a reply to "Proposal:
Integrate static analysis test suites", the fact
that static analysis generates a totally
different set of warnings than compilation (not
a superset), is surprising to some.</div>
<div><br>
</div>
<div>One possibility, in order to preserve the
current behavior for any tools that rely on
this, is to add an option to clang, something
like "-enable-analyze-pass" that the user can
specify to run analysis AND compilation.</div>
<div><br>
</div>
<div>Thoughts?</div>
<br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr"><span
style="font-size:12.8px">Sincerely,</span><br
style="font-size:12.8px">
<span style="font-size:12.8px">Alexander
Riccio</span><br
style="font-size:12.8px">
<span style="font-size:12.8px">--</span><br
style="font-size:12.8px">
<span style="font-size:12.8px">"Change
the world or go home."</span>
<div style="font-size:12.8px"><a
moz-do-not-send="true"
href="http://about.me/ariccio"
target="_blank">about.me/ariccio</a></div>
<div style="font-size:12.8px"><a
moz-do-not-send="true"
href="http://about.me/ariccio"
target="_blank"><br>
</a></div>
<div style="font-size:12.8px">If left to
my own devices, I will build more.</div>
<div style="font-size:12.8px">⁂</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
cfe-dev mailing list
<a moz-do-not-send="true" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><span class="HOEnZb"><font color="#888888">
</font></span></pre>
<span class="HOEnZb"><font color="#888888"> </font></span></blockquote>
<span class="HOEnZb"><font color="#888888"> <br>
<pre cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</font></span></div>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</body>
</html>