diff options
author | Shuxin Yang <shuxin.llvm@gmail.com> | 2013-04-05 21:07:08 +0000 |
---|---|---|
committer | Shuxin Yang <shuxin.llvm@gmail.com> | 2013-04-05 21:07:08 +0000 |
commit | 2da70d1792abf0ad837578991f492a3dd0364118 (patch) | |
tree | c6398e42bfae8720c8420faecebc9e7476317bb0 /lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp | |
parent | 84058c9accd075a5e785906ab9e7aae03d3d7e8d (diff) | |
download | llvm-2da70d1792abf0ad837578991f492a3dd0364118.tar.gz llvm-2da70d1792abf0ad837578991f492a3dd0364118.tar.bz2 llvm-2da70d1792abf0ad837578991f492a3dd0364118.tar.xz |
Disable the optimization about promoting vector-element-access with symbolic index.
This optimization is unstable at this moment; it
1) block us on a very important application
2) PR15200
3) test6 and test7 in test/Transforms/ScalarRepl/dynamic-vector-gep.ll
(the CHECK command compare the output against wrong result)
I personally believe this optimization should not have any impact on the
autovectorized code, as auto-vectorizer is supposed to put gather/scatter
in a "right" way. Although in theory downstream optimizaters might reveal
some gather/scatter optimization opportunities, the chance is quite slim.
For the hand-crafted vectorizing code, in term of redundancy elimination,
load-CSE, copy-propagation and DSE can collectively achieve the same result,
but in much simpler way. On the other hand, these optimizers are able to
improve the code in a incremental way; in contrast, SROA is sort of all-or-none
approach. However, SROA might slighly win in stack size, as it tries to figure
out a stretch of memory tightenly cover the area accessed by the dynamic index.
rdar://13174884
PR15200
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178912 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp')
0 files changed, 0 insertions, 0 deletions