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.
From vectorization theory point On top of viewthat, we don't have to reject all cases of stores to uniform addresses.just above the assertion, Eventually,we check for unit-strided load/store or
gather scatter. we should support safe/profitable casesAddresses can't be uniform below that check.
This patch resolves the issue by removing useless assertions that is invoking LAA's isUniform() that requires up-to-date DomTree.
Assert is replaced by a TODO comment on how one could enable vectorization of "store to uniform address" and why LAA's isUniform()
should not be used in trying to optimize that.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 useless assertions that is invoking LAA's isUniform() that requires up-to-date DomTree ---- once vector code gen starts modifying CFG, See below for further discussionswe don't have an up-to-date DomTree.