diff options
author | Arnold Schwaighofer <aschwaighofer@apple.com> | 2013-02-05 15:08:02 +0000 |
---|---|---|
committer | Arnold Schwaighofer <aschwaighofer@apple.com> | 2013-02-05 15:08:02 +0000 |
commit | 22174f5d5af1eb15b376c6d49e7925cbb7cca6be (patch) | |
tree | 694bbab472d3d60f6f96496e7697587ab826b497 /clang/lib/Frontend/FrontendAction.cpp | |
parent | 36017454ac374449570e685aee5d697ee7d3f8de (diff) | |
download | llvm-22174f5d5af1eb15b376c6d49e7925cbb7cca6be.zip llvm-22174f5d5af1eb15b376c6d49e7925cbb7cca6be.tar.gz llvm-22174f5d5af1eb15b376c6d49e7925cbb7cca6be.tar.bz2 |
Loop Vectorizer: Handle pointer stores/loads in getWidestType()
In the loop vectorizer cost model, we used to ignore stores/loads of a pointer
type when computing the widest type within a loop. This meant that if we had
only stores/loads of pointers in a loop we would return a widest type of 8bits
(instead of 32 or 64 bit) and therefore a vector factor that was too big.
Now, if we see a consecutive store/load of pointers we use the size of a pointer
(from data layout).
This problem occured in SingleSource/Benchmarks/Shootout-C++/hash.cpp (reduced
test case is the first test in vector_ptr_load_store.ll).
radar://13139343
llvm-svn: 174377
Diffstat (limited to 'clang/lib/Frontend/FrontendAction.cpp')
0 files changed, 0 insertions, 0 deletions