summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp
diff options
context:
space:
mode:
authorShuxin Yang <shuxin.llvm@gmail.com>2013-04-05 21:07:08 +0000
committerShuxin Yang <shuxin.llvm@gmail.com>2013-04-05 21:07:08 +0000
commit95adf5258f69a072f5cbc00110e7a1500589622a (patch)
tree0e8a430dd3ec27a2aa0e6d1ccbf75081c5148ea5 /llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp
parent2ec76747f4f5166017a832cf738154786afdcbb9 (diff)
downloadbcm5719-llvm-95adf5258f69a072f5cbc00110e7a1500589622a.tar.gz
bcm5719-llvm-95adf5258f69a072f5cbc00110e7a1500589622a.zip
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 llvm-svn: 178912
Diffstat (limited to 'llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud