| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This file will be useful for filling in the gaps where `six` is
missing some things we need.
llvm-svn: 251847
|
| |
|
|
| |
llvm-svn: 251846
|
| |
|
|
| |
llvm-svn: 251845
|
| |
|
|
|
|
| |
for language support
llvm-svn: 251844
|
| |
|
|
| |
llvm-svn: 251843
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The hasBase and hasIndex don't tell anything about the position of the
base and the index in the code, so we need hasLHS and hasRHS in some cases.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D14212
llvm-svn: 251842
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r251837, due to a number of bot failures of the form:
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function
loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined
reference to
'llvm::object::FunctionIndexObjectFile::create(llvm::MemoryBufferRef,
llvm::LLVMContext&, llvm::Module const*, bool)'
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function
loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined
reference to 'llvm::object::FunctionIndexObjectFile::takeIndex()'
I'm not sure why these are happening - I added Object to the requred
libraries in tools/llvm-link/LLVMBuild.txt and the LLVM_LINK_COMPONENTS
in tools/llvm-link/CMakeLists.txt. Confirmed for my build that these
symbols come out of libLLVMObject.a. What am I missing?
llvm-svn: 251841
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has apparently been broken since June, but only on non-Windows.
Perhaps nobody noticed it because if the symlink is already there
it won't try to re-create it, and nobody ever tried doing a clean
build.
In any case, I will let the original author attempt to fix this if
he is still interested. the problem is that in the normal case
of not setting BUILD_SHARED_LIBS and simply running ninja, it would
link _lldb.so to a non-existent location, creating a dangling
symlink.
llvm-svn: 251840
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loop preheader
Summary:
This patch adds support to check if a loop has loop invariant conditions which lead to loop exits. If so, we know that if the exit path is taken, it is at the first loop iteration. If there is an induction variable used in that exit path whose value has not been updated, it will keep its initial value passing from loop preheader. We can therefore rewrite the exit value with
its initial value. This will help remove phis created by LCSSA and enable other optimizations like loop unswitch.
Reviewers: sanjoy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13974
llvm-svn: 251839
|
| |
|
|
|
|
| |
Language plugin before using the C-style rule
llvm-svn: 251838
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Support for necessary linkage changes and symbol renaming during
ThinLTO function importing.
Also includes llvm-link support for manually importing functions
and associated llvm-link based tests.
Note that this does not include support for intelligently importing
metadata, which is currently imported duplicate times. That support will
be in the follow-on patch, and currently is ignored by the tests.
Reviewers: dexonsmith, joker.eph, davidxl
Subscribers: tobiasvk, tejohnson, llvm-commits
Differential Revision: http://reviews.llvm.org/D13515
llvm-svn: 251837
|
| |
|
|
|
|
| |
swap directly. No real change.
llvm-svn: 251836
|
| |
|
|
| |
llvm-svn: 251835
|
| |
|
|
| |
llvm-svn: 251834
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data is available.
In the current BB placement algorithm, a loop chain always contains all loop blocks. This has a drawback that cold blocks in the loop may be inserted on a hot function path, hence increasing branch cost and also reducing icache locality.
Consider a simple example shown below:
A
|
B⇆C
|
D
When B->C is quite cold, the best BB-layout should be A,B,D,C. But the current implementation produces A,C,B,D.
This patch filters those cold blocks off from the loop chain by comparing the ratio:
LoopBBFreq / LoopFreq
to 20%: if it is less than 20%, we don't include this BB to the loop chain. Here LoopFreq is the frequency of the loop when we reduce the loop into a single node. In general we have more cold blocks when the loop has few iterations. And vice versa.
Differential revision: http://reviews.llvm.org/D11662
llvm-svn: 251833
|
| |
|
|
| |
llvm-svn: 251832
|
| |
|
|
|
|
|
| |
We'll hook this up to the main page after Greg, Sean and others
iterate on it to a useful point.
llvm-svn: 251831
|
| |
|
|
| |
llvm-svn: 251830
|
| |
|
|
|
|
| |
This found a bug in Clang's PTH implementation.
llvm-svn: 251829
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This came up in a boost build, which apparently uses PTH. This was
broken in r187619 when we migrated it to uses llvm::fs instead of raw
stat calls.
Constructing a test case with a hash table collision in-tree is tough.
Instead, I have a pending change to OnDiskChainedHashTable that asserts
that the reported length of the data agrees with the data actually
written. All of the existing in-tree tests find the bug with this
assert.
llvm-svn: 251828
|
| |
|
|
|
|
|
| |
This was flagged by ASAN when using a test case I will be committing
along with D13515.
llvm-svn: 251827
|
| |
|
|
| |
llvm-svn: 251826
|
| |
|
|
|
|
|
| |
- SUN_LEN doesn't work because strlen(sun_path) == 0
- sizeof(sockaddr_un) doesn't work on Android.
llvm-svn: 251825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unaffected lines with incorrect initial indent.
Starting from:
namespace {
int i; // There shouldn't be indentation here.
int j; // <- call clang-format on this line.
}
Before:
namespace {
int i;
int j;
}
After:
namespace {
int i;
int j;
}
llvm-svn: 251824
|
| |
|
|
| |
llvm-svn: 251823
|
| |
|
|
|
|
|
|
| |
I think the underlying problem was fixed by r251819, but I can't
reproduce the problem. So this is to check whether it does in
fact fix the problem.
llvm-svn: 251822
|
| |
|
|
|
|
| |
As in other contexts, alignments can go up to 16 bytes in a va_list.
llvm-svn: 251821
|
| |
|
|
|
|
|
|
|
|
|
| |
The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
packages/Python/lldbsuite is now a Python package, and it relies
on its __init__.py being called to do package-level initialization.
If you exec packages/Python/lldbsuite/dotest.py directly, you won't
get this package level initialization, and things will fail. But
without this patch, this is exactly what dosep itself does. To
launch the multi-processing fork, it was hardcoding a path to
dotest.py and exec'ing it from inside the package.
The fix here is to get the path of the top-level script, and
then exec'ing that instead. A more robust solution would involve
refactoring the code so that dosep execs some internal script that
imports lldbsuite, but that's a bit more involved.
Differential Revision: http://reviews.llvm.org/D14157
Reviewed by: Todd Fiala
llvm-svn: 251819
|
| |
|
|
|
|
|
|
| |
Remove code that was assuming that this would never work.
Thanks to Colin LeMahie for finding and diagnosing the bug.
llvm-svn: 251818
|
| |
|
|
| |
llvm-svn: 251817
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) PR25154. This is basically a repeat of PR18102, which was fixed in
r200201, and broken again by r234430. The latter changed which of the
store nodes was merged into from the first to the last. Thus, we now
also need to prefer merging a later store at a given address into the
target node, instead of an earlier one.
2) While investigating that, I also realized I'd introduced a bug in
r236850. There, I removed a check for alignment -- not realizing that
nothing except the alignment check was ensuring that none of the stores
were overlapping! This is a really bogus way to ensure there's no
aliased stores.
A better solution to both of these issues is likely to always use the
code added in the 'if (UseAA)' branches which rearrange the chain based
on a more principled analysis. I'll look into whether that can be used
always, but in the interest of getting things back to working, I think a
minimal change makes sense.
llvm-svn: 251816
|
| |
|
|
| |
llvm-svn: 251815
|
| |
|
|
| |
llvm-svn: 251814
|
| |
|
|
|
|
|
| |
I had clang formatted my earlier patches using the wrong style.
Reformatted with the LLVM style.
llvm-svn: 251813
|
| |
|
|
|
|
|
| |
I had clang formatted my earlier patches using the wrong style.
Reformatted with the LLVM style.
llvm-svn: 251812
|
| |
|
|
| |
llvm-svn: 251811
|
| |
|
|
|
|
|
| |
This reduces the number of .cpp files needed to be rebuilt after
touching OnDiskHashTable from 120 to 21 for me.
llvm-svn: 251810
|
| |
|
|
|
|
|
|
| |
Reviewed By: hfinkel
Differential Revision: http://reviews.llvm.org/D13953
llvm-svn: 251809
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now, it detects that several kinds of usages are can't modify the elements. Examples:
-When an usage is a call to a const member function or operator of the element.
-If the element is used as an argument to a function or constructor that takes a const-reference or a value.
-LValue to RValue conversion, if the element is a fundamental type (which allows the use of most of the builtin operators).
Reviewers: klimek
Subscribers: cfe-commits, alexfh
Differential Revision: http://reviews.llvm.org/D14198
llvm-svn: 251808
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The check was assuming that a definition of a function always has a body, but a declaration that explicitly defaults or deletes a function is a definition too.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D14238
llvm-svn: 251807
|
| |
|
|
|
|
|
| |
The existing -v option only displays commands and outputs for failed
tests, the newly introduced -a displays it for all executed tests.
llvm-svn: 251806
|
| |
|
|
| |
llvm-svn: 251805
|
| |
|
|
|
|
| |
unitialized_copy tests
llvm-svn: 251804
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: When traversing the parent map, the check assumed that all the nodes would be either Stmt or Decl. After r251101, this is no longer true: there can be TypeLoc and NestedNameSpecifierLoc nodes.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D14229
llvm-svn: 251803
|
| |
|
|
|
|
| |
heads-up.
llvm-svn: 251802
|
| |
|
|
| |
llvm-svn: 251801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
SCEV Predicates represent conditions that typically cannot be derived from
static analysis, but can be used to reduce SCEV expressions to forms which are
usable for different optimizers.
ScalarEvolution now has the rewriteUsingPredicate method which can simplify a
SCEV expression using a SCEVPredicateSet. The normal workflow of a pass using
SCEVPredicates would be to hold a SCEVPredicateSet and every time assumptions
need to be made a new SCEV Predicate would be created and added to the set.
Each time after calling getSCEV, the user will call the rewriteUsingPredicate
method.
We add two types of predicates
SCEVPredicateSet - implements a set of predicates
SCEVEqualPredicate - tests for equality between two SCEV expressions
We use the SCEVEqualPredicate to re-implement stride versioning. Every time we
version a stride, we will add a SCEVEqualPredicate to the context.
Instead of adding specific stride checks, LoopVectorize now adds a more
generic SCEV check.
We only need to add support for this in the LoopVectorizer since this is the
only pass that will do stride versioning.
Reviewers: mzolotukhin, anemet, hfinkel, sanjoy
Subscribers: sanjoy, hfinkel, rengolin, jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D13595
llvm-svn: 251800
|
| |
|
|
| |
llvm-svn: 251799
|
| |
|
|
|
|
|
|
|
|
| |
This revision has introduced an issue that only affects bootstrapped compiler
when it is printing the ASM. It turns out that the new code path taken due to
legalizing a scalar_to_vector of i64 -> v2i64 exposes a missing check in a
micro optimization to change a load followed by a scalar_to_vector into a
load and splat instruction on PPC.
llvm-svn: 251798
|