3 Commits

Author SHA1 Message Date
Cameron Zwarich
3ebb05d9a6 When scalar replacement returns a vector type, only accept it if the vector
type's bitwidth matches the (allocated) size of the alloca. This severely
pessimizes vector scalar replacement when the only vector type being used is
something like <3 x float> on x86 or ARM whose allocated size matches a
<4 x float>.

I hope to fix some of the flawed assumptions about allocated size throughout
scalar replacement and reenable this in most cases.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133338 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-18 06:17:51 +00:00
Cameron Zwarich
96cc1d0dfb Fix PR10104 by adding a bounds check on a vector element access check. It was
assuming that all offsets are legal vector accesses, and thus trying to access
the float member of { <2 x float>, float } as the 3rd element of the first
member.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132766 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-09 01:45:33 +00:00
Cameron Zwarich
0398d6135d Fix an assymmetry between ConvertScalar_ExtractValue and ConvertScalar_InsertValue. The
former was using the size of the entire alloca, whereas the latter was correctly using
the allocated size of the immediate type being converted (which may differ from the size
of the alloca). This fixes PR10082.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132759 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-08 22:08:31 +00:00