[analyzer] Print Inline mode with -analyzer-display-progress.

llvm-svn: 174244

[analyzer] Make shallow mode more shallow.

Redefine the shallow mode to inline all functions for which we have a
definite definition (ipa=inlining). However, only inline functions that
are up to 4 b

[analyzer] Make shallow mode more shallow.

Redefine the shallow mode to inline all functions for which we have a
definite definition (ipa=inlining). However, only inline functions that
are up to 4 basic blocks large and cut the max exploded nodes generated
per top level function in half.

This makes shallow faster and allows us to keep inlining small
functions. For example, we would keep inlining wrapper functions and
constructors/destructors.

With the new shallow, it takes 104s to analyze sqlite3, whereas
the deep mode is 658s and previous shallow is 209s.

llvm-svn: 173958

show more ...

Re-sort #include lines using the llvm/utils/sort_includes.py script.

Removes a duplicate #include as well as cleaning up some sort order
regressions since I last ran the script over Clang.

llvm-svn

Re-sort #include lines using the llvm/utils/sort_includes.py script.

Removes a duplicate #include as well as cleaning up some sort order
regressions since I last ran the script over Clang.

llvm-svn: 171364

show more ...

[analyzer] Re-apply r170826 and make the dumping of the GallGraph
deterministic.

Commit message for r170826:

[analyzer] Traverse the Call Graph in topological order.

Modify the call graph by remov

[analyzer] Re-apply r170826 and make the dumping of the GallGraph
deterministic.

Commit message for r170826:

[analyzer] Traverse the Call Graph in topological order.

Modify the call graph by removing the parentless nodes. Instead all
nodes are children of root to ensure they are all reachable. Remove the
tracking of nodes that are "top level" or global. This information is
not used and can be obtained from the Decls stored inside
CallGraphNodes.

Instead of existing ordering hacks, analyze the functions in topological
order over the Call Graph.

Together with the addition of devirtualizable ObjC message sends and
blocks to the call graph, this gives around 6% performance improvement
on several large ObjC benchmarks.

llvm-svn: 170906

show more ...

Revert r170826. The output of

./bin/clang -cc1 -internal-isystem /home/espindola/llvm/build/lib/clang/3.3/include/ -analyze -analyzer-checker=debug.DumpCallGraph /home/espindola/llvm/clang/test/Anal

Revert r170826. The output of

./bin/clang -cc1 -internal-isystem /home/espindola/llvm/build/lib/clang/3.3/include/ -analyze -analyzer-checker=debug.DumpCallGraph /home/espindola/llvm/clang/test/Analysis/debug-CallGraph.c -fblocks

changes in each run.

llvm-svn: 170829

show more ...

[analyzer] Traverse the Call Graph in topological order.

Modify the call graph by removing the parentless nodes. Instead all
nodes are children of root to ensure they are all reachable. Remove the
t

[analyzer] Traverse the Call Graph in topological order.

Modify the call graph by removing the parentless nodes. Instead all
nodes are children of root to ensure they are all reachable. Remove the
tracking of nodes that are "top level" or global. This information is
not used and can be obtained from the Decls stored inside
CallGraphNodes.

Instead of existing ordering hacks, analyze the functions in topological
order over the Call Graph.

Together with the addition of devirtualizable ObjC message sends and
blocks to the call graph, this gives around 6% performance improvement
on several large ObjC benchmarks.

llvm-svn: 170826

show more ...

[analyzer] Add blocks and ObjC messages to the call graph.

This paves the road for constructing a better function dependency graph.
If we analyze a function before the functions it calls and inlines

[analyzer] Add blocks and ObjC messages to the call graph.

This paves the road for constructing a better function dependency graph.
If we analyze a function before the functions it calls and inlines,
there is more opportunity for optimization.

Note, we add call edges to the called methods that correspond to
function definitions (declarations with bodies).

llvm-svn: 170825

show more ...

Pass AnalyzerOptions to PathDiagnosticConsumer to make analyzer options accessible there.

This is plumbing needed for later functionality changes.

llvm-svn: 170488

[analyzer] Tweak the NumFunctionsAnalyzed stat so that it's more useful.

llvm-svn: 170362

[analyzer] Refactor: Store visited Decls instead of CallGraphNodes.

llvm-svn: 170231

[analyzer] Optimization heuristic: do not reanalyze every ObjC method as
top level.

This heuristic is already turned on for non-ObjC methods
(inlining-mode=noredundancy). If a method has been previo

[analyzer] Optimization heuristic: do not reanalyze every ObjC method as
top level.

This heuristic is already turned on for non-ObjC methods
(inlining-mode=noredundancy). If a method has been previously analyzed,
while being inlined inside of another method, do not reanalyze it as top
level.

This commit applies it to ObjCMethods as well. The main caveat here is
that to catch the retain release errors, we are still going to reanalyze
all the ObjC methods but without inlining turned on.

Gives 21% performance increase on one heavy ObjC benchmark, which
suffered large performance regressions due to ObjC inlining.

llvm-svn: 169639

show more ...

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/util

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237

show more ...

[analyzer] Don't run non-path-sensitive checks on system headers...

...but do run them on user headers.

Previously, we were inconsistent here: non-path-sensitive checks on code
/bodies/ were only r

[analyzer] Don't run non-path-sensitive checks on system headers...

...but do run them on user headers.

Previously, we were inconsistent here: non-path-sensitive checks on code
/bodies/ were only run in the main source file, but checks on
/declarations/ were run in /all/ headers. Neither of those is the
behavior we want.

Thanks to Sujit for pointing this out!

<rdar://problem/12454226>

llvm-svn: 165635

show more ...

[analyzer] Fix typo: s/HandleDeclsGallGraph/HandleDeclsCallGraph/g

No functionality change.

llvm-svn: 165634

[analyzer] Do not visit ObjCMethodDecl twice in the AST checkers.

llvm-svn: 164869

Make AnalyzerOptions a shared object between CompilerInvocation and
AnalysisManager, allowing the StringMap of configuration values to
be propagated.

llvm-svn: 162978

Move AnalyzerOptions.h into 'Core' StaticAnalyzer sub-library.

llvm-svn: 162977

[analyzer] Ensure that PathDiagnostics profile the same regardless of path.

PathDiagnostics are actually profiled and uniqued independently of the
path on which the bug occurred. This is used to mer

[analyzer] Ensure that PathDiagnostics profile the same regardless of path.

PathDiagnostics are actually profiled and uniqued independently of the
path on which the bug occurred. This is used to merge diagnostics that
refer to the same issue along different paths, as well as by the plist
diagnostics to reference files created by the HTML diagnostics.

However, there are two problems with the current implementation:

1) The bug description is included in the profile, but some
PathDiagnosticConsumers prefer abbreviated descriptions and some
prefer verbose descriptions. Fixed by including both descriptions in
the PathDiagnostic objects and always using the verbose one in the profile.

2) The "minimal" path generation scheme provides extra information about
which events came from macros that the "extensive" scheme does not.
This resulted not only in different locations for the plist and HTML
diagnostics, but also in diagnostics being uniqued in the plist output
but not in the HTML output. Fixed by storing the "end path" location
explicitly in the PathDiagnostic object, rather than trying to find the
last piece of the path when the diagnostic is requested.

This should hopefully finish unsticking our internal buildbot.

llvm-svn: 162965

show more ...

[analyzer] Refactor the logic that determines if a functions should be
reanalyzed.

The policy on what to reanalyze should be in AnalysisConsumer with the
rest of visitation order logic.

There is no

[analyzer] Refactor the logic that determines if a functions should be
reanalyzed.

The policy on what to reanalyze should be in AnalysisConsumer with the
rest of visitation order logic.

There is no reason why ExprEngine needs to pass the Visited set to
CoreEngine, it can populate it itself.

llvm-svn: 162957

show more ...

Rename 'VisualizeEGUbi' and 'VisualizeEGDot' to 'visualizeExplodedGraphWithUbigGraph'
and 'visualizeExplodedGraphWithGraphViz' respectively.

llvm-svn: 162931

Store const& to AnalyzerOptions in AnalysisManager instead of copying
individual flags.

llvm-svn: 162929

Move AnalyzerOptions.h to include/clang/StaticAnalyzer.

llvm-svn: 162928

Move Analyses.def to include/clang/StaticAnalyzer.

llvm-svn: 162927

Add new -cc1 driver option -analyzer-config, which allows one to specify
a comma separated collection of key:value pairs (which are strings). This
allows a general way to provide analyzer configurat

Add new -cc1 driver option -analyzer-config, which allows one to specify
a comma separated collection of key:value pairs (which are strings). This
allows a general way to provide analyzer configuration data from the command line.

No clients yet.

llvm-svn: 162827

show more ...

Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.

This fixes several issues:

- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnos

Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.

This fixes several issues:

- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.

- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).

As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.

There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.

llvm-svn: 162028

show more ...