Chandler Carruth 2402e6315d [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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220116 91177308-0d34-0410-b5e6-96231b3b80d8		2014-10-18 00:44:02 +00:00
..
address-spaces.ll
alignment.ll
basictest.ll
big-endian.ll
fca.ll
phi-and-select.ll	SROA: Don't insert instructions before a PHI	2014-09-01 21:20:14 +00:00
slice-order-independence.ll
slice-width.ll	Add a test case for SROA where the store size is bigger than slice size. The	2014-08-22 23:27:04 +00:00
vector-conversion.ll
vector-lifetime-intrinsic.ll
vector-promotion.ll	[SROA] Change how SROA does vector-based promotion of allocas to handle	2014-10-18 00:44:02 +00:00
vectors-of-pointers.ll