| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
constructors. Fixes PR12219.
llvm-svn: 152470
|
| |
|
|
| |
llvm-svn: 152469
|
| |
|
|
|
|
|
|
|
|
|
| |
doesn't understand. We registered
as aborted, but didn't treat such cases as sinks in the ExplodedGraph.
Along the way, add basic support for CXXCatchStmt, expanding the set of code we actually analyze (hopefully correctly).
Fixes: <rdar://problem/10892489>
llvm-svn: 152468
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- We do this when it is easy to determine that the backend will pass them on
the stack properly by itself.
Currently LLVM codegen is really bad in some cases with byval, for example, on
the test case here (which is derived from Sema code, which likes to pass
SourceLocations around)::
struct s47 { unsigned a; };
void f47(int,int,int,int,int,int,struct s47);
void test47(int a, struct s47 b) { f47(a, a, a, a, a, a, b); }
we used to emit code like this::
...
movl %esi, -8(%rbp)
movl -8(%rbp), %ecx
movl %ecx, (%rsp)
...
to handle moving the struct onto the stack, which is just appalling.
Now we generate::
movl %esi, (%rsp)
which seems better, no?
llvm-svn: 152462
|
| |
|
|
| |
llvm-svn: 152461
|
| |
|
|
|
|
| |
// rdar://11023563
llvm-svn: 152459
|
| |
|
|
|
|
| |
innermost type. Fixes PR12142.
llvm-svn: 152456
|
| |
|
|
|
|
|
|
| |
copy-construction, which Daniel Dunbar reports as giving a 0.75% speedup on
403.gcc/combine.c. The performance differences on my constexpr torture tests
are below the noise floor.
llvm-svn: 152455
|
| |
|
|
|
|
| |
ivars in the modern rewriter.
llvm-svn: 152451
|
| |
|
|
|
|
| |
annotations. Fixes <rdar://problem/10824732>.
llvm-svn: 152448
|
| |
|
|
|
|
|
|
|
|
| |
basic source character set in C++98. Add -Wc++98-compat diagnostics for same in
literals in C++11. Extend such support to cover string literals as well as
character literals, and mark N2170 as done.
This seems too minor to warrant a release note to me. Let me know if you disagree.
llvm-svn: 152444
|
| |
|
|
|
|
| |
actually happened.
llvm-svn: 152442
|
| |
|
|
| |
llvm-svn: 152441
|
| |
|
|
|
|
|
|
|
|
|
| |
We do not reanalyze a function, which has already been analyzed as an
inlined callee. As per PRELIMINARY testing, this gives over
50% run time reduction on some benchmarks without decreasing of the
number of bugs found.
Turning the mode on by default.
llvm-svn: 152440
|
| |
|
|
| |
llvm-svn: 152439
|
| |
|
|
|
|
|
|
| |
invalid ParmVarDecls.
Part of rdar://11007039.
llvm-svn: 152437
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an error made a record member invalid, the record would stay as "isBeingDefined" and
not "completeDefinition". Even easily recoverable errors ended up propagating records in
such "beingDefined" state, for example:
struct A {
~A() const; // expected-error {{'const' qualifier is not allowed on a destructor}}
};
struct B : A {}; // A & B would stay as "not complete definition" and "being defined".
This weird state was impending lookups in the records and hitting assertion in the ASTWriter.
Part of rdar://11007039
llvm-svn: 152432
|
| |
|
|
|
|
| |
LLVM_READONLY.
llvm-svn: 152428
|
| |
|
|
|
|
|
| |
to forward class, and assigning to an 'id' type var, message
sends default to 'id'. // rdar"//10988847
llvm-svn: 152420
|
| |
|
|
|
|
|
|
|
| |
- getSourceRange().getBegin() is about as awesome a pattern as .copy().size().
I already killed the hot paths so this doesn't seem to impact performance on my
tests-of-the-day, but it is a much more sensible (and shorter) pattern.
llvm-svn: 152419
|
| |
|
|
|
|
|
| |
- This cuts the # of getSourceRange calls by 60% on
OGF/NSBezierPath-OAExtensions.m.
llvm-svn: 152412
|
| |
|
|
|
|
|
|
| |
- getSourceRange() can be very expensive, we should try to avoid it if at all possible.
In conjunction with the previous commit I measured a ~2% speedup on 403.gcc/combine.c and a 3% speedup on OmniGroupFrameworks/NSBezierPath-OAExtensions.m.
llvm-svn: 152411
|
| |
|
|
|
|
|
|
| |
methods.
- There are probably a lot more of these worth adding, but these are a start at hitting some of the exprs for which getSourceRange().getBegin() is a poor substitute for getLocStart().
llvm-svn: 152410
|
| |
|
|
|
|
| |
more obvious.
llvm-svn: 152408
|
| |
|
|
|
|
|
|
|
| |
This renames the -Wformat-non-standard flag to -Wformat-non-iso,
rewords the current warnings a bit (pointing out that a format string
is not supported by ISO C rather than being "non standard"),
and adds a warning about positional arguments.
llvm-svn: 152403
|
| |
|
|
| |
llvm-svn: 152401
|
| |
|
|
| |
llvm-svn: 152396
|
| |
|
|
| |
llvm-svn: 152395
|
| |
|
|
| |
llvm-svn: 152394
|
| |
|
|
|
|
| |
and lots of tidying up.
llvm-svn: 152392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- On -emit-llvm-only of 403.gcc/combine.c, for example, we make 160k calls to
getTypeInfo but only ever deal with 680 some distinct types.
I saw these speedups (user time):
403.gcc/combine.c -- 3.1%
OmniGroupFrameworks/NSBezierPath-OAExtensions.m -- 3.6%
JavaScriptCore/Interpreter.cpp -- 1.4%
which seems pretty sweet.
I ran some histograms on those compiles and we end up doing a ton of
getTypeInfo() on 'char' and 'int'. I tried splitting out a fast path for builtin
types, but this wasn't a win. Still kinda seems like we could be doing better
here.
llvm-svn: 152377
|
| |
|
|
|
|
|
| |
type-analysis; otherwise, we just completely do the
wrong thing for placeholders.
llvm-svn: 152375
|
| |
|
|
|
|
| |
rebuild a global because of the initializer. <rdar://problem/10957867>.
llvm-svn: 152372
|
| |
|
|
|
|
| |
correctly. Part of <rdar://problem/10957867>.
llvm-svn: 152370
|
| |
|
|
| |
llvm-svn: 152365
|
| |
|
|
| |
llvm-svn: 152364
|
| |
|
|
|
|
|
| |
- This function is not at all free; pass it around along some hot paths instead
of recomputing it deep inside various VarDecl methods.
llvm-svn: 152363
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
symbols and regions.
Essentially, a bug centers around a story for various symbols and regions. We should only include
the path diagnostic events that relate to those symbols and regions.
The pruning is done by associating a set of interesting symbols and regions with a BugReporter, which
can be modified at BugReport creation or by BugReporterVisitors.
This patch reduces the diagnostics emitted in several of our test cases. I've vetted these as
having desired behavior. The only regression is a missing null check diagnostic for the return
value of realloc() in test/Analysis/malloc-plist.c. This will require some investigation to fix,
and I have added a FIXME to the test case.
llvm-svn: 152361
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
analyzed.
The CallGraph is used when inlining is on, which is the current default.
This alone does not bring any performance improvement. It's a
stepping stone for the upcoming optimization in which we do not
re-analyze a function that has already been analyzed while inlined in
other functions. Using the call graph makes it easier to play with
the order of functions to minimize redundant analyzes.
llvm-svn: 152352
|
| |
|
|
|
|
|
|
|
| |
- Remove -analyzer-inline-call.
- Add -analyzer-ipa=[none|inlining]
- Add -analyzer-inlining-mode to allow experimentation for
different performance tuning methods.
llvm-svn: 152351
|
| |
|
|
| |
llvm-svn: 152350
|
| |
|
|
|
|
|
|
|
|
|
|
| |
for a few kinds of error. Specifically:
Since we're after translation phase 6, the "" token might be formed by multiple
source-level string literals. Checking the token width is not a correct way of
detecting empty string literals, due to escaped newlines. Diagnose and recover
from a missing space between "" and suffix, and from string literals other than
"", which are followed by a suffix.
llvm-svn: 152348
|
| |
|
|
|
|
| |
introduces cleanups anyway.
llvm-svn: 152345
|
| |
|
|
|
|
|
| |
first codepoint! Also, don't reject empty raw string literals for spurious
"encoding" issues. Also, don't rely on undefined behavior in ConvertUTF.c.
llvm-svn: 152344
|
| |
|
|
|
|
| |
CXXTemporaryObjectExprs, not just CXXConstructExprs, which have a worrying tendency to vanish. Fixes PR12167.
llvm-svn: 152340
|
| |
|
|
| |
llvm-svn: 152339
|
| |
|
|
| |
llvm-svn: 152331
|
| |
|
|
|
|
|
| |
- This change seems to be a tiny loss on 403.gcc/combine.c (.2%), but I think
it is the right thing to do.
llvm-svn: 152330
|
| |
|
|
|
|
| |
incredibly common) path.
llvm-svn: 152321
|
| |
|
|
|
|
| |
HandleCXXStaticMemberVarInstantiation. Suggested by Argyrios.
llvm-svn: 152320
|