aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/FrontendAction.cpp
diff options
context:
space:
mode:
authorArnold Schwaighofer <aschwaighofer@apple.com>2013-02-05 15:08:02 +0000
committerArnold Schwaighofer <aschwaighofer@apple.com>2013-02-05 15:08:02 +0000
commit22174f5d5af1eb15b376c6d49e7925cbb7cca6be (patch)
tree694bbab472d3d60f6f96496e7697587ab826b497 /clang/lib/Frontend/FrontendAction.cpp
parent36017454ac374449570e685aee5d697ee7d3f8de (diff)
downloadllvm-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