| Age | Commit message (Collapse) | Author |
|---|
|
Pure optimization, no functionality change. Probably does not make much
of a difference, but it's free.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176229 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176043 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ExplodedNode pruning.
r175988 modified the ExplodedGraph trimming algorithm to retain all
nodes for "lvalue" expressions. This patch refines that notion to
only "interesting" expressions that would be used for diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176010 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fields.
This required more changes than I originally expected:
- ObjCIvarRegion implements "canPrintPretty" et al
- DereferenceChecker indicates the null pointer source is an ivar
- bugreporter::trackNullOrUndefValue() uses an alternate algorithm
to compute the location region to track by scouring the ExplodedGraph.
This allows us to get the actual MemRegion for variables, ivars,
fields, etc. We only hand construct a VarRegion for C++ references.
- ExplodedGraph no longer drops nodes for expressions that are marked
'lvalue'. This is to facilitate the logic in the previous bullet.
This may lead to a slight increase in size in the ExplodedGraph,
which I have not measured, but it is likely not to be a big deal.
I have validated each of the changed plist output.
Fixes <rdar://problem/12114812>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175988 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This provides a few sundry cleanups, and allows us to provide
a compile-time check for a case that was a runtime assertion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, we had the decisions about inlining spread out
over multiple functions.
In addition to the refactor, this commit ensures
that we will always inline BodyFarm functions as long as the Decl
is available. This fixes false positives due to those functions
not being inlined when no or minimal inlining is enabled such (as
shallow mode).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a follow-up to r175830, which made sure a temporary object region
created for, say, a struct rvalue matched up with the initial bindings
being stored into it. This does the same for the case in which the AST
actually tells us that we need to create a temporary via a
MaterializeObjectExpr. I've unified the two code paths and moved a static
helper function onto ExprEngine.
This also caused a bit of test churn, causing us to go back to describing
temporary regions without a 'const' qualifier. This seems acceptable; it's
our behavior from a few months ago.
<rdar://problem/13265460> (part 2)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
See r175462 for another example/more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175812 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows MemRegion and MemRegionManager to avoid asking over and over
again whether an class is a virtual base or a non-virtual base.
Minor optimization/cleanup; no functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175716 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175705 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also document TypeLoc's operations similarly, since it's a good idea.
Post-commit CR feedback from Anna Zaks regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175694 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Post-commit CR feedback from Jordan Rose regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Post-commit CR feedback from Jordan Rose regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175676 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
See r175462 for another example/more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175594 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also removes some redundant DNI comments on function declarations already
using the macro.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...after a host of optimizations related to the use of LazyCompoundVals
(our implementation of aggregate binds).
Originally applied in r173951.
Reverted in r174069 because it was causing hangs.
Re-applied in r174212.
Reverted in r174265 because it was /still/ causing hangs.
If this needs to be reverted again it will be punted to far in the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175234 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174782 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The checkPointerEscape callback previously did not specify how a
pointer escaped. This change includes an enum which describes the
different ways a pointer may escape. This enum is passed to the
checkPointerEscape callback when a pointer escapes. If the escape
is due to a function call, the call is passed. This changes
previous behavior where the call is passed as NULL if the escape
was due to indirectly invalidating the region the pointer referenced.
A patch by Branden Archer!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174677 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a more natural order of evaluation, and it is very important
for visualization in the static analyzer. Within Xcode, the arrows
will not jump from right to left, which looks very visually jarring.
It also provides a more natural location for dataflow-based diagnostics.
Along the way, we found a case in the analyzer diagnostics where we
needed to indicate that a variable was "captured" by a block.
-fsyntax-only timings on sqlite3.c show no visible performance change,
although this is just one test case.
Fixes <rdar://problem/13016513>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...again. The problem has not been fixed and our internal buildbot is still
getting hangs.
This reverts r174212, originally applied in r173951, then reverted in r174069.
Will not re-apply until the entire project analyzes successfully on my
local machine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174265 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
With the optimization in the previous commit, this should be safe again.
Originally applied in r173951, then reverted in r174069.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows us to keep from chaining LazyCompoundVals in cases like this:
CGRect r = CGRectMake(0, 0, 640, 480);
CGRect r2 = r;
CGRect r3 = r2;
Previously we only made this optimization if the struct did not begin with
an aggregate member, to make sure that we weren't picking up an LCV for
the first field of the struct. But since LazyCompoundVals are typed, we can
make that inference directly by comparing types.
This is a pure optimization; the test changes are to guard against possible
future regressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174211 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It's causing hangs on our internal analyzer buildbot. Will restore after
investigating.
This reverts r173951 / baa7ca1142990e1ad6d4e9d2c73adb749ff50789.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174069 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173958 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173957 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173956 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is faster for the analyzer to process than inlining the constructor
and performing a member-wise copy, and it also solves the problem of
warning when a partially-initialized POD struct is copied.
Before:
CGPoint p;
p.x = 0;
CGPoint p2 = p; <-- assigned value is garbage or undefined
After:
CGPoint p;
p.x = 0;
CGPoint p2 = p; // no-warning
This matches our behavior in C, where we don't see a field-by-field copy.
<rdar://problem/12305288>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173951 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows it to be used in places where the interesting statement
doesn't match up with the current node. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173546 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This should be used for testing only. Path pruning is still on by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173545 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"Prune" is the term for eliminating pieces of a path that are not
relevant to the user. "Suppress" means don't show that path at all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173544 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173392 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The idea is to introduce a higher level "user mode" option for
different use scenarios. For example, if one wants to run the analyzer
for a small project each time the code is built, they would use
the "shallow" mode.
The user mode option will influence the default settings for the
lower-level analyzer options. For now, this just influences the ipa
modes, but we plan to find more optimal settings for them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173386 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Suppress the warning by just not emitting the report. The sink node
would get generated, which is fine since we did reach a bad state.
Motivation
Due to the way code is structured in some of these macros, we do not
reason correctly about it and report false positives. Specifically, the
following loop reports a use-after-free. Because of the way the code is
structured inside of the macro, the analyzer assumes that the list can
have cycles, so you end up with use-after-free in the loop, that is
safely deleting elements of the list. (The user does not have a way to
teach the analyzer about shape of data structures.)
SLIST_FOREACH_SAFE(item, &ctx->example_list, example_le, tmpitem) {
if (item->index == 3) { // if you remove each time, no complaints
assert((&ctx->example_list)->slh_first == item);
SLIST_REMOVE(&ctx->example_list, item, example_s, example_le);
free(item);
}
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172883 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172595 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This should fix cast-away-const warnings reported by David Greene.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172446 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by David Greene, modified by me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172445 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
brought into 'clang' namespace by clang/Basic/LLVM.h
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
other headers included before them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172320 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
With the new setting, we are not going to inline any functions that are
more than 50 basic blocks. (The analyzer is 20% faster on several
especially bad benchmarks with the new default.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The issue here is that if we have 2 leaks reported at the same line for
which we cannot print the corresponding region info, they will get
treated as the same by issue_hash+description. We need to AUGMENT the
issue_hash with the allocation info to differentiate the two issues.
Add the "hash" (offset from the beginning of a function) representing
allocation site to solve the issue.
We might want to generalize solution in the future when we decide to
track more than just the 2 locations from the diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171825 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This better reflects when callback is called and what the checkers
are relying on. (Both names meant the same pre-IPA.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171432 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Unfortunately, we don't seem to have a standard way to do this. I'm using
the __OPTIMIZE__ GNU extension that Clang also defines, but that doesn't
help MSVC. I suppose we could remove the check entirely, but it's useful
for developing new constraint managers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170915 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170832 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Instead of using several callbacks to identify the pointer escape event,
checkers now can register for the checkPointerEscape.
Converted the Malloc checker to use the new callback.
SimpleStreamChecker will be converted next.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170625 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
accessible there.
This is plumbing needed for later functionality changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170488 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
contexts.
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
max-times-inline-large=xx
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
expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169640 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169639 91177308-0d34-0410-b5e6-96231b3b80d8
|
