[SROA] Change how SROA does vector-based promotion of allocas to handle
authorChandler Carruth <chandlerc@gmail.com>
Sat, 18 Oct 2014 00:44:02 +0000 (00:44 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Sat, 18 Oct 2014 00:44:02 +0000 (00:44 +0000)
commit2dc9682e59af4f5a8b1797e16085028316d12477
tree2fb9acf11cce442e615293fc5092b514076a1e82
parent24b7dd431e34956bdde79220e3e4b23e70a78284
[SROA] Change how SROA does vector-based promotion of allocas to handle
cases where the alloca type, the load types, and the store types used
all disagree.

Previously, the only way that vector-based promotion occured was if the
alloca type was a vector type. This was one of the *very* few remaining
uses of the alloca's type to guide SROA/mem2reg left in LLVM. It turns
out it was a bad idea.

The alloca type can change very easily based on the mixture of types
loaded and stored to that alloca. We shouldn't be relying on it as
a signal for very much. Instead, the source of truth should be loads and
stores. We should canonicalize the loads and stores as much as possible
and then rely on them exclusively in SROA.

When looking and loads and stores, we may find many different candidate
vector types. This change will let SROA try all of them to find a vector
type which is a viable way to promote the entire alloca to a vector
register.

With this change, it becomes possible to do better canonicalization and
optimization of loads and stores without breaking SROA in random ways,
and that should allow fixing a core source of performance loss in hot
numerical loops such as those in Eigen.

llvm-svn: 220116
llvm/lib/Transforms/Scalar/SROA.cpp
llvm/test/Transforms/SROA/vector-promotion.ll