History log of /external/clang/include/clang/StaticAnalyzer/Core/PathSensitive/FunctionSummary.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
c9092bb5eb67d859122abb69a0ef61e9249500cd 02-Apr-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Cache whether a function is generally inlineable.

Certain properties of a function can determine ahead of time whether or not
the function is inlineable, such as its kind, its signature, or its
location. We can cache this value in the FunctionSummaries map to avoid
rechecking these static properties for every call.

Note that the analyzer may still decide not to inline a specific call to
a function because of the particular dynamic properties of the call along
the current path.

No intended functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178515 91177308-0d34-0410-b5e6-96231b3b80d8
992acb2269171b6ef68694d71a36f6b7408d8e82 02-Apr-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Use inline storage in the FunctionSummary DenseMap.

The summaries lasted for the lifetime of the map anyway; no reason to
include an extra allocation.

Also, use SmallBitVector instead of BitVector to track the visited basic
blocks -- most functions will have less than 64 basic blocks -- and
use bitfields for the other fields to reduce the size of the structure.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178514 91177308-0d34-0410-b5e6-96231b3b80d8
7959671d456c916706a5f61af609d8f1fc95decf 17-Dec-2012 Anna Zaks <ganna@apple.com> [analyzer] Implement "do not inline large functions many times"
performance heuristic

After inlining a function with more than 13 basic blocks 32 times, we
are not going to inline it anymore. The idea is that inlining large
functions leads to drastic performance implications. Since the function
has already been inlined, we know that we've analyzed it in many

The following metrics are used:
- Large function is a function with more than 13 basic blocks (we
should switch to another metric, like cyclomatic complexity)
- We consider that we've inlined a function many times if it's been
inlined 32 times. This number is configurable with -analyzer-config

This heuristic addresses a performance regression introduced with
inlining on one benchmark. The analyzer on this benchmark became 60
times slower with inlining turned on. The heuristic allows us to analyze
it in 24% of the time. The performance improvements on the other
benchmarks I've tested with are much lower - under 10%, which is

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170361 91177308-0d34-0410-b5e6-96231b3b80d8
30a2e16f6c27f888dd11eba6bbbae1e980078fcb 04-Dec-2012 Chandler Carruth <chandlerc@gmail.com> Sort #include lines for all files under include/...

This is a simpler sort, entirely automatic with the help of
llvm/utils/sort_includes.py -- no manual edits here.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169238 91177308-0d34-0410-b5e6-96231b3b80d8
577f14a34457032523e59dbbbacb88ca2cd4db57 27-Apr-2012 Ted Kremenek <kremenek@apple.com> Use a deque instead of an ImmutableList in AnalysisConsumer to preserve the file order that functions are visited. Should fix the buildbots.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155693 91177308-0d34-0410-b5e6-96231b3b80d8
cb0a5039c243f5b0c178e70f424adac334e5789b 27-Apr-2012 Ted Kremenek <kremenek@apple.com> Change FunctionSummary.h's definition of SetOfDecls to be an ImmutableList instead
of a mutable SmallPtrSet. While iterating over LocalTUDecls, there were cases
where we could modify LocalTUDecls, which could result in invalidating an iterator
and an analyzer crash. Along the way, switch some uses of std::queue to std::dequeue,
which should be slightly more efficient.

Unfortunately, this is a difficult case to create a test case for.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155680 91177308-0d34-0410-b5e6-96231b3b80d8
6a86082f3a06a2dcceaaf63f78a0e52d64bcbaa3 13-Apr-2012 Anna Zaks <ganna@apple.com> [analyzer] PCH deserialization optimization.

We should not deserialize unused declarations from the PCH file. Achieve
this by storing the top level declarations during parsing
(HandleTopLevelDecl ASTConsumer callback) and analyzing/building a call
graph only for those.

Tested the patch on a sample ObjC file that uses PCH. With the patch,
the analyzes is 17.5% faster and clang consumes 40% less memory.
Got about 10% overall build/analyzes time decrease on a large Objective
C project.

A bit of CallGraph refactoring/cleanup as well..

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154625 91177308-0d34-0410-b5e6-96231b3b80d8
cd863466b97cee866370bc6ff75370628ab01d37 05-Apr-2012 Anna Zaks <ganna@apple.com> [analyzer] Add a coverage calculation to FunctionSummaries.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154076 91177308-0d34-0410-b5e6-96231b3b80d8
e62f048960645b79363408fdead53fec2a063c52 03-Apr-2012 Anna Zaks <ganna@apple.com> [analyzer] Record the basic blocks covered by the analyzes run.

Store this info inside the function summary generated for all analyzed
functions. This is useful for coverage stats and can be helpful for
analyzer state space search strategies.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153923 91177308-0d34-0410-b5e6-96231b3b80d8