| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 187340
|
|
|
|
|
|
| |
handled by the SelectionDAG store-vectorizer, which does a better job in deciding when to vectorize.
llvm-svn: 187267
|
|
|
|
|
|
| |
as <3 x float>, because we dont have a good cost model for these types.
llvm-svn: 187265
|
|
|
|
|
|
| |
that create a cycle. We already break the cycle on phi-nodes, but arithmetic operations are still uplicated. This patch adds code that checks if the operation that we are vectorizing was vectorized during the visit of the operands and uses this value if it can.
llvm-svn: 186883
|
|
|
|
|
|
| |
Compares return i1 but they compare different types.
llvm-svn: 186359
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functionality change.
This update was done with the following bash script:
find test/Transforms -name "*.ll" | \
while read NAME; do
echo "$NAME"
if ! grep -q "^; *RUN: *llc" $NAME; then
TEMP=`mktemp -t temp`
cp $NAME $TEMP
sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \
while read FUNC; do
sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP
done
mv $TEMP $NAME
fi
done
llvm-svn: 186268
|
|
|
|
| |
llvm-svn: 186145
|
|
|
|
|
|
|
|
| |
successor blocks with code that scans PHINodes.
Before we could vectorize PHINodes scanning successors was a good way of finding candidates. Now we can vectorize the phinodes which is simpler.
llvm-svn: 186139
|
|
|
|
| |
llvm-svn: 186063
|
|
|
|
| |
llvm-svn: 186062
|
|
|
|
| |
llvm-svn: 186060
|
|
|
|
|
|
| |
the bundle are uniform.
llvm-svn: 185970
|
|
|
|
|
|
|
|
|
| |
This is a complete re-write if the bottom-up vectorization class.
Before this commit we scanned the instruction tree 3 times. First in search of merge points for the trees. Second, for estimating the cost. And finally for vectorization.
There was a lot of code duplication and adding the DCE exposed bugs. The new design is simpler and DCE was a part of the design.
In this implementation we build the tree once. After that we estimate the cost by scanning the different entries in the constructed tree (in any order). The vectorization phase also works on the built tree.
llvm-svn: 185774
|
|
|
|
|
|
|
| |
To support this we have to insert 'extractelement' instructions to pick the right lane.
We had this functionality before but I removed it when we moved to the multi-block design because it was too complicated.
llvm-svn: 185230
|
|
|
|
| |
llvm-svn: 184969
|
|
|
|
|
|
| |
consider them as a candidate for replacement of instructions to be visited.
llvm-svn: 184966
|
|
|
|
| |
llvm-svn: 184888
|
|
|
|
|
|
|
|
|
|
|
|
| |
Untill now we detected the vectorizable tree and evaluated the cost of the
entire tree. With this patch we can decide to trim-out branches of the tree
that are not profitable to vectorizer.
Also, increase the max depth from 6 to 12. In the worse possible case where all
of the code is made of diamond-shaped graph this can bring the cost to 2**10,
but diamonds are not very common.
llvm-svn: 184681
|
|
|
|
|
|
|
|
| |
sequences.
Make sure that we don't replace and RAUW two sequences if one does not dominate the other.
llvm-svn: 184674
|
|
|
|
| |
llvm-svn: 184660
|
|
|
|
|
|
|
|
|
| |
Rewrote the SLP-vectorization as a whole-function vectorization pass. It is now able to vectorize chains across multiple basic blocks.
It still does not vectorize PHIs, but this should be easy to do now that we scan the entire function.
I removed the support for extracting values from trees.
We are now able to vectorize more programs, but there are some serious regressions in many workloads (such as flops-6 and mandel-2).
llvm-svn: 184647
|
|
|
|
|
|
|
| |
We collect gather sequences when we vectorize basic blocks. Gather sequences are excellent
hints for vectorization of other basic blocks.
llvm-svn: 184444
|
|
|
|
|
|
| |
ExtractElementInst).
llvm-svn: 184325
|
|
|
|
|
|
|
|
| |
The type <3 x i8> is a common in graphics and we want to be able to vectorize it.
This changes accelerates bullet by 12% and 471_omnetpp by 5%.
llvm-svn: 184317
|
|
|
|
| |
llvm-svn: 184282
|
|
|
|
|
|
|
|
|
|
|
|
| |
function.
We are not working on a DAG and I ran into a number of problems when I enabled the vectorizations of 'diamond-trees' (trees that share leafs).
* Imroved the numbering API.
* Changed the placement of new instructions to the last root.
* Fixed a bug with external tree users with non-zero lane.
* Fixed a bug in the placement of in-tree users.
llvm-svn: 182508
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This will make it easier to turn on struct-path aware TBAA since the metadata
format will change.
llvm-svn: 180796
|
|
|
|
| |
llvm-svn: 179975
|
|
|
|
| |
llvm-svn: 179960
|
|
|
|
| |
llvm-svn: 179930
|
|
|
|
|
|
| |
vector-gather sequence out of loops.
llvm-svn: 179562
|
|
|
|
|
|
|
|
|
|
|
| |
I can fix the testcases here:
http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/6952
This reverts commit r179512 due to testcases specifying triples
that they didn't actually mean and causing failures on other platforms.
llvm-svn: 179513
|
|
|
|
| |
llvm-svn: 179512
|
|
|
|
|
|
| |
instructions.
llvm-svn: 179504
|
|
|
|
|
|
| |
This reverts commit r179497 and the accompanying commit as it broke random platforms that aren't osx.
llvm-svn: 179499
|
|
|
|
| |
llvm-svn: 179498
|
|
|
|
| |
llvm-svn: 179492
|
|
|
|
| |
llvm-svn: 179476
|
|
|
|
|
|
| |
and add the cost of extracting values from the roots of the tree.
llvm-svn: 179475
|
|
|
|
| |
llvm-svn: 179470
|
|
|
|
|
|
| |
perform a preliminary traversal of the graph to collect values with multiple users and check where the users came from.
llvm-svn: 179414
|
|
|
|
|
|
| |
function calls when we check if it is safe to sink instructions.
llvm-svn: 179207
|
|
This commit adds the infrastructure for performing bottom-up SLP vectorization (and other optimizations) on parallel computations.
The infrastructure has three potential users:
1. The loop vectorizer needs to be able to vectorize AOS data structures such as (sum += A[i] + A[i+1]).
2. The BB-vectorizer needs this infrastructure for bottom-up SLP vectorization, because bottom-up vectorization is faster to compute.
3. A loop-roller needs to be able to analyze consecutive chains and roll them into a loop, in order to reduce code size. A loop roller does not need to create vector instructions, and this infrastructure separates the chain analysis from the vectorization.
This patch also includes a simple (100 LOC) bottom up SLP vectorizer that uses the infrastructure, and can vectorize this code:
void SAXPY(int *x, int *y, int a, int i) {
x[i] = a * x[i] + y[i];
x[i+1] = a * x[i+1] + y[i+1];
x[i+2] = a * x[i+2] + y[i+2];
x[i+3] = a * x[i+3] + y[i+3];
}
llvm-svn: 179117
|