[LV] Fix vectorizer's isUniform() abuse triggers assert in SCEV
authorRenato Golin <renato.golin@linaro.org>
Fri, 9 Mar 2018 10:31:31 +0000 (10:31 +0000)
committerRenato Golin <renato.golin@linaro.org>
Fri, 9 Mar 2018 10:31:31 +0000 (10:31 +0000)
commit6b62039bb0c035bea854d68a86394d42fb15256b
treef24c460f0d6196946763d58a9ff839fbe3d9a7a3
parent692175399453d70083772033e13a11e408576327
[LV] Fix vectorizer's isUniform() abuse triggers assert in SCEV

Fixes PR36311.

See more detailed analysis in
https://bugs.llvm.org/show_bug.cgi?id=36311.

isUniform() information is recomputed after LV started transforming the
underlying IR and that triggered an assert in SCEV.

From vectorizer's architectural perspective, such information, while
still useful in vector code gen, should not be recomputed after the
start of transforming the LLVM IR. Instead, we should collect and cache
such information during the analysis phase of LV and use the cached info
during code gen.

From the symptom perspective, this assert as it stands right now is not
very useful. Legality already rejected loops that would trigger the
assert. As such, commenting out the assert is NFC from vectorizer's
functionality perspective. On top of that, just above the assertion, we
check for unit-strided load/store or
gather scatter. Addresses can't be uniform below that check.

From vectorization theory point of view, we don't have to reject all
cases of stores to uniform addresses. Eventually, we should support
safe/profitable cases.

This patch resolves the issue by removing the useless assertion that is
invoking LAA's isUniform() that requires up-to-date DomTree ---- once
vector code gen starts modifying CFG, we don't have an up-to-date
DomTree.

Patch by Hideki Saito <hideki.saito@intel.com>.

llvm-svn: 327109
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp