Summary:
This allows for a better alternative to the FrontendAction hack used in
clang-tidy in order to get static analyzer's ASTConsumer.
Reviewers: jordan_rose, krememek
Reviewed By: jordan_rose
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2505
llvm-svn: 198426
The loop rerolling pass was failing with an assertion failure from a
failed cast on loops like this:
void foo(int *A, int *B, int m, int n) {
for (int i = m; i < n; i+=4) {
A[i+0] = B[i+0] * 4;
A[i+1] = B[i+1] * 4;
A[i+2] = B[i+2] * 4;
A[i+3] = B[i+3] * 4;
}
}
The code was casting the SCEV-expanded code for the new
induction variable to a phi-node. When the loop had a non-constant
lower bound, the SCEV expander would end the code expansion with an
add insted of a phi node and the cast would fail.
It looks like the cast to a phi node was only needed to get the
induction variable value coming from the backedge to compute the end
of loop condition. This patch changes the loop reroller to compare
the induction variable to the number of times the backedge is taken
instead of the iteration count of the loop. In other words, we stop
the loop when the current value of the induction variable ==
IterationCount-1. Previously, the comparison was comparing the
induction variable value from the next iteration == IterationCount.
This problem only seems to occur on 32-bit targets. For some reason,
the loop is not rerolled on 64-bit targets.
PR18290
llvm-svn: 198425
Summary:
Made ClangTidyAction more slim and moved its declaration to header to
allow easy creation of Clang-tidy ASTConsumer. Don't derive from
clang::ento::AnalysisAction, use clang::ento::CreateAnalysisConsumer instead
(I'll propose making this function a part of a public API in a separate patch).
Use MultiplexConsumer instead of a custom class.
Don't re-filter checkers list for each TU.
Reviewers: klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2481
llvm-svn: 198402
Back out the part of r198399 that enabled LLVM_FINAL/LLVM_OVERRIDE on VS 2010.
DwarfUnit.h legitimately uses them on destructors which unfortunately triggers
Compiler Error C3665 (override specifier not allowed on a destructor/finalizer)
prior to MSVC 2012:
virtual ~DwarfCompileUnit() LLVM_OVERRIDE;
llvm-svn: 198401
cycles
This allows the value equality check to work even if we don't have a dominator
tree. Also add some more comments.
I was worried about compile time impacts and did not implement reachability but
used the dominance check in the initial patch. The trade-off was that the
dominator tree was required.
The llvm utility function isPotentiallyReachable cuts off the recursive search
after 32 visits. Testing did not show any compile time regressions showing my
worries unjustfied.
No compile time or performance regressions at O3 -flto -mavx on test-suite +
externals.
Addresses review comments from r198290.
llvm-svn: 198400
The 'sealed' definition of LLVM_FINAL can be dropped once VS 2010 is
decommissioned.
Some of this is speculative so will keep an eye on the waterfall -- ping me if
you see failures.
Incremental work towards C++11 migration.
llvm-svn: 198399
What's good for LTO metadata size problems ought to be good for non-LTO
debug info size too, so let's rely on the same uniqueness in both cases.
If it's insufficient for non-LTO for whatever reason (since we now won't
be uniquing CU-local types or any C types - but these are likely to not
be the most significant contributors to type bloat) we should consider a
frontend solution that'll help both LTO and non-LTO alike, rather than
using DWARF-level DIE-hashing that only helps non-LTO debug info size.
It's also much simpler this way and benefits C++ even more since we can
deduplicate lexically separate definitions of the same C++ type since
they have the same mangled name.
llvm-svn: 198397
The cgo problem was that it wants dwarf2 which doesn't support direct
constant encoding of the location. So let's add support for dwarf2
encoding (using a location expression) of data member locations.
This reverts commit r198385.
llvm-svn: 198389
Summary:
No functionality change.
This code should live here long-term because we should be able to use it
to compute correct vftable names.
It turns out that the most natural way to implement the naming algorithm
is to use a caching layer similar to what we already have for virtual
table info in VTableContext. Subsequent changes will take advantage of
this to fix PR17748, where we have a vbtable name collision.
Reviewers: majnemer
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2499
llvm-svn: 198380
This functionality was enabled by r198374. Here's a test to ensure it
works and we don't regress it.
Based on a patch by Maciej Piechotka.
llvm-svn: 198377
This ModulePass schedules the set of Polly canonicalization passes. It is a
debugging tool that can be used to preoptimize .ll files for Polly processing.
llvm-svn: 198376
Marshall Clow