| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
the iteration step is -1
llvm-svn: 171114
|
|
|
|
| |
llvm-svn: 171076
|
|
|
|
| |
llvm-svn: 171043
|
|
|
|
|
|
|
|
| |
the StoreInst operands.
PR14705.
llvm-svn: 171023
|
|
|
|
|
|
|
|
| |
The bug was in the code that detects PHIs in if-then-else block sequence.
PR14701.
llvm-svn: 171008
|
|
|
|
|
|
|
|
| |
the cost of arithmetic functions. We now assume that the cost of arithmetic
operations that are marked as Legal or Promote is low, but ops that are
marked as custom are higher.
llvm-svn: 171002
|
|
|
|
|
|
| |
them more expensive.
llvm-svn: 170995
|
|
|
|
|
|
|
|
|
|
| |
memory bound checks. Before the fix we were able to vectorize this loop from
the Livermore Loops benchmark:
for ( k=1 ; k<n ; k++ )
x[k] = x[k-1] + y[k];
llvm-svn: 170811
|
|
|
|
|
|
|
|
|
|
| |
Before if-conversion we could check if a value is loop invariant
if it was declared inside the basic block. Now that loops have
multiple blocks this check is incorrect.
This fixes External/SPEC/CINT95/099_go/099_go
llvm-svn: 170756
|
|
|
|
|
|
|
|
|
| |
- An MVT can become an EVT when being split (e.g. v2i8 -> v1i8, the latter doesn't exist)
- Return the scalar value when an MVT is scalarized (v1i64 -> i64)
Fixes PR14639ff.
llvm-svn: 170546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of scalar operations.
For example on x86 with SSE4.2 a <8 x i8> add reduction becomes
movdqa %xmm0, %xmm1
movhlps %xmm1, %xmm1 ## xmm1 = xmm1[1,1]
paddw %xmm0, %xmm1
pshufd $1, %xmm1, %xmm0 ## xmm0 = xmm1[1,0,0,0]
paddw %xmm1, %xmm0
phaddw %xmm0, %xmm0
pextrb $0, %xmm0, %edx
instead of
pextrb $2, %xmm0, %esi
pextrb $0, %xmm0, %edx
addb %sil, %dl
pextrb $4, %xmm0, %esi
addb %dl, %sil
pextrb $6, %xmm0, %edx
addb %sil, %dl
pextrb $8, %xmm0, %esi
addb %dl, %sil
pextrb $10, %xmm0, %edi
pextrb $14, %xmm0, %edx
addb %sil, %dil
pextrb $12, %xmm0, %esi
addb %dil, %sil
addb %sil, %dl
llvm-svn: 170439
|
|
|
|
|
|
| |
induction variables costs the same as scalar trunc.
llvm-svn: 170051
|
|
|
|
|
|
| |
increase the function size.
llvm-svn: 170004
|
|
|
|
|
|
| |
in if-conversion.
llvm-svn: 169916
|
|
|
|
|
|
| |
truncation is now done on scalars.
llvm-svn: 169904
|
|
|
|
| |
llvm-svn: 169813
|
|
|
|
|
|
|
| |
while (i--)
sum+=A[i];
llvm-svn: 169752
|
|
|
|
|
|
|
|
|
| |
- added function to VectorTargetTransformInfo to query cost of intrinsics
- vectorize trivially vectorizable intrinsic calls such as sin, cos, log, etc.
Reviewed by: Nadav
llvm-svn: 169711
|
|
|
|
|
|
|
| |
reduction variable is not used outside the loop then we ran into an
endless loop. This change checks if we found the original PHI.
llvm-svn: 169324
|
|
|
|
| |
llvm-svn: 169288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the code that actually performs the if-conversion during vectorization.
We can now vectorize this code:
for (int i=0; i<n; ++i) {
unsigned k = 0;
if (a[i] > b[i]) <------ IF inside the loop.
k = k * 5 + 3;
a[i] = k; <---- K is a phi node that becomes vector-select.
}
llvm-svn: 169217
|
|
|
|
|
|
| |
induction variable.
llvm-svn: 168558
|
|
|
|
|
|
|
|
| |
example: *dst++ = *src++).
At the moment we still require to have an integer induction variable (for example: i++).
llvm-svn: 168231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously in a vector of pointers, the pointer couldn't be any pointer type,
it had to be a pointer to an integer or floating point type. This is a hassle
for dragonegg because the GCC vectorizer happily produces vectors of pointers
where the pointer is a pointer to a struct or whatever. Vector getelementptr
was restricted to just one index, but now that vectors of pointers can have
any pointer type it is more natural to allow arbitrary vector getelementptrs.
There is however the issue of struct GEPs, where if each lane chose different
struct fields then from that point on each lane will be working down into
unrelated types. This seems like too much pain for too little gain, so when
you have a vector struct index all the elements are required to be the same.
llvm-svn: 167828
|
|
|
|
|
|
|
| |
If the arrays are found to be disjoint then we run the vectorized version of
the loop. If they are not, we run the scalar code.
llvm-svn: 167608
|
|
|
|
| |
llvm-svn: 167480
|
|
|
|
| |
llvm-svn: 167412
|
|
|
|
| |
llvm-svn: 167395
|
|
|
|
| |
llvm-svn: 167174
|
|
|
|
|
|
| |
bitcasts cost zero.
llvm-svn: 167170
|
|
|
|
| |
llvm-svn: 167101
|
|
|
|
|
|
|
| |
This is important for loops in the LAPACK test-suite.
These loops start at 1 because they are auto-converted from fortran.
llvm-svn: 167084
|
|
|
|
|
|
|
|
| |
is a single pointer.
Speedup SciMark by 1%
llvm-svn: 167035
|
|
|
|
|
|
|
|
| |
needs to start at all-one
while XOR, and OR need to start at zero.
llvm-svn: 167032
|
|
|
|
|
|
|
|
|
| |
return the type of the split result.
2. Change the maximum vectorization width from 4 to 8.
3. A test for both.
llvm-svn: 166864
|
|
|
|
|
|
|
|
|
|
| |
Add getCostXXX calls for different families of opcodes, such as casts, arithmetic, cmp, etc.
Port the LoopVectorizer to the new API.
The LoopVectorizer now finds instructions which will remain uniform after vectorization. It uses this information when calculating the cost of these instructions.
llvm-svn: 166836
|
|
|
|
|
|
| |
that only run if the target is present.
llvm-svn: 166796
|
|
|
|
| |
llvm-svn: 166722
|
|
|
|
| |
llvm-svn: 166718
|
|
|
|
|
|
| |
Patch by Paul Redmond <paul.redmond@intel.com>.
llvm-svn: 166649
|
|
|
|
| |
llvm-svn: 166642
|
|
|
|
| |
llvm-svn: 166620
|
|
|
|
|
|
|
|
| |
and c++ news.
PR14158.
llvm-svn: 166491
|
|
|
|
|
|
| |
Fix by Shivarama Rao <Shivarama.Rao@amd.com>
llvm-svn: 166427
|
|
|
|
|
|
| |
generate a scalar-cond select (i1 as selector).
llvm-svn: 166409
|
|
|
|
|
|
|
|
| |
We used a SCEV to detect that A[X] is consecutive. We assumed that X was
the induction variable. But X can be any expression that uses the induction
for example: X = i + 2;
llvm-svn: 166388
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is important for nested-loop reductions such as :
In the innermost loop, the induction variable does not start with zero:
for (i = 0 .. n)
for (j = 0 .. m)
sum += ...
llvm-svn: 166387
|
|
|
|
| |
llvm-svn: 166384
|
|
|
|
|
|
| |
PR14134.
llvm-svn: 166379
|
|
|
|
|
|
|
|
|
| |
A[B[i]]+=x.
If the pointer is consecutive then it is safe to read and write. If the pointer is non-loop-consecutive then
it is unsafe to vectorize it because we may hit an ordering issue.
llvm-svn: 166371
|