| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
We used to give up if we saw two integer inductions. After this patch, we base
further induction variables on the chosen one like we do in the reverse
induction and pointer induction case.
Fixes PR15720.
radar://13851975
llvm-svn: 181746
|
| |
|
|
|
|
| |
read in asserts.
llvm-svn: 181689
|
| |
|
|
| |
llvm-svn: 181684
|
| |
|
|
|
|
|
|
| |
multiple users.
The external user does not have to be in lane #0. We have to save the lane for each scalar so that we know which vector lane to extract.
llvm-svn: 181674
|
| |
|
|
|
|
|
|
| |
round of vectorization.
Testcase in the next commit.
llvm-svn: 181673
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the widest induction type encountered for the cannonical induction variable.
We used to turn the following loop into an empty loop because we used i8 as
induction variable type and truncated 1024 to 0 as trip count.
int a[1024];
void fail() {
int reverse_induction = 1023;
unsigned char forward_induction = 0;
while ((reverse_induction) >= 0) {
forward_induction++;
a[reverse_induction] = forward_induction;
--reverse_induction;
}
}
radar://13862901
llvm-svn: 181667
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 181666
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 181665
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For example:
bar() {
int a = A[i];
int b = A[i+1];
B[i] = a;
B[i+1] = b;
foo(a); <--- a is used outside the vectorized expression.
}
llvm-svn: 181648
|
| |
|
|
| |
llvm-svn: 181647
|
| |
|
|
|
|
|
|
|
| |
A computable loop exit count does not imply the presence of an induction
variable. Scalar evolution can return a value for an infinite loop.
Fixes PR15926.
llvm-svn: 181495
|
| |
|
|
|
|
|
| |
The two nested loops were confusing and also conservative in identifying
reduction variables. This patch replaces them by a worklist based approach.
llvm-svn: 181369
|
| |
|
|
|
|
|
|
|
|
| |
We were passing an i32 to ConstantInt::get where an i64 was needed and we must
also pass the sign if we pass negatives numbers. The start index passed to
getConsecutiveVector must also be signed.
Should fix PR15882.
llvm-svn: 181286
|
| |
|
|
| |
llvm-svn: 181178
|
| |
|
|
| |
llvm-svn: 181157
|
| |
|
|
|
|
|
|
|
|
| |
Add support for min/max reductions when "no-nans-float-math" is enabled. This
allows us to assume we have ordered floating point math and treat ordered and
unordered predicates equally.
radar://13723044
llvm-svn: 181144
|
| |
|
|
|
|
|
|
|
| |
No need for setting the operands. The pointers are going to be bound by the
matcher.
radar://13723044
llvm-svn: 181142
|
| |
|
|
|
|
|
|
|
|
| |
We can just use the initial element that feeds the reduction.
max(max(x, y), z) == max(max(x,y), max(x,z))
radar://13723044
llvm-svn: 181141
|
| |
|
|
|
|
|
|
| |
constructor enables
Patch by Robert Wilhelm.
llvm-svn: 181138
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
values.
By supporting the vectorization of PHINodes with more than two incoming values we can increase the complexity of nested if statements.
We can now vectorize this loop:
int foo(int *A, int *B, int n) {
for (int i=0; i < n; i++) {
int x = 9;
if (A[i] > B[i]) {
if (A[i] > 19) {
x = 3;
} else if (B[i] < 4 ) {
x = 4;
} else {
x = 5;
}
}
A[i] = x;
}
}
llvm-svn: 181037
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
llvm-svn: 180881
|
| |
|
|
| |
llvm-svn: 180806
|
| |
|
|
|
|
| |
based on the numbers of reads and writes.
llvm-svn: 180593
|
| |
|
|
|
|
| |
readonly pointers.
llvm-svn: 180570
|
| |
|
|
|
|
|
|
| |
This makes it easier to read the code.
No functionality change.
llvm-svn: 180197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch disables memory-instruction vectorization for types that need padding
bytes, e.g., x86_fp80 has 10 bytes store size with 6 bytes padding in darwin on
x86_64. Because the load/store vectorization is performed by the bit casting to
a packed vector, which has incompatible memory layout due to the lack of padding
bytes, the present vectorizer produces inconsistent result for memory
instructions of those types.
This patch checks an equality of the AllocSize of a scalar type and allocated
size for each vector element, to ensure that there is no padding bytes and the
array can be read/written using vector operations.
Patch by Daisuke Takahashi!
Fixes PR15758.
llvm-svn: 180196
|
| |
|
|
| |
llvm-svn: 180195
|
| |
|
|
|
|
|
|
| |
that the order in which the elements are scalarized is the same as the original order.
This fixes a miscompilation in FreeBSD's regex library.
llvm-svn: 180121
|
| |
|
|
|
|
| |
Made the uniform write test's checks a bit stricter.
llvm-svn: 180119
|
| |
|
|
|
|
|
|
|
| |
even if erroneously annotated with the parallel loop metadata.
Fixes Bug 15794:
"Loop Vectorizer: Crashes with the use of llvm.loop.parallel metadata"
llvm-svn: 180081
|
| |
|
|
|
|
|
| |
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.
llvm-svn: 180063
|
| |
|
|
| |
llvm-svn: 179975
|
| |
|
|
|
|
|
|
| |
with multiple users.
We did not terminate the switch case and we executed the search routine twice.
llvm-svn: 179974
|
| |
|
|
| |
llvm-svn: 179960
|
| |
|
|
| |
llvm-svn: 179936
|
| |
|
|
|
|
| |
Avoids a couple of copies and allows more flexibility in the clients.
llvm-svn: 179935
|
| |
|
|
|
|
| |
the more expensive patterns. After this change will only check basic arithmetic trees that start at cmpinstr.
llvm-svn: 179933
|
| |
|
|
|
|
| |
lists.
llvm-svn: 179932
|
| |
|
|
| |
llvm-svn: 179931
|
| |
|
|
| |
llvm-svn: 179930
|
| |
|
|
| |
llvm-svn: 179929
|
| |
|
|
| |
llvm-svn: 179928
|
| |
|
|
| |
llvm-svn: 179927
|
| |
|
|
|
|
|
|
|
| |
Also make some static function class functions to avoid having to mention the
class namespace for enums all the time.
No functionality change intended.
llvm-svn: 179886
|
| |
|
|
| |
llvm-svn: 179789
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A min/max operation is represented by a select(cmp(lt/le/gt/ge, X, Y), X, Y)
sequence in LLVM. If we see such a sequence we can treat it just as any other
commutative binary instruction and reduce it.
This appears to help bzip2 by about 1.5% on an imac12,2.
radar://12960601
llvm-svn: 179773
|
| |
|
|
|
|
| |
Fixes PR15748.
llvm-svn: 179757
|
| |
|
|
|
|
| |
vector-gather sequence out of loops.
llvm-svn: 179562
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 179504
|
| |
|
|
| |
llvm-svn: 179483
|