Suggested in code review by Eli.

That code in InstCombine looks kinda suspicious.

llvm-svn: 145013

llvm-svn: 144442

element types, even though the element extraction code does. It is surprising
that this bug has been here for so long. Fixes <rdar://problem/10318778>.

llvm-svn: 142740

would have never worked, since the element type of a vector type is never a
vector type. Also fix the conditional to be more direct in checking whether
EltTy is a vector type.

llvm-svn: 141713

lowering of NEON code. It provides little-to-no benefit now and only introduces
additional complexity.

llvm-svn: 141646

Stop emitting instructions with the name "tmp" they eat up memory and have to be uniqued, without any benefit.

If someone prefers %tmp42 to %42, run instnamer.

llvm-svn: 140634

llvm-svn: 140327

No tests; these changes aren't really interesting in the sense that the logic is the same for volatile and atomic.

I believe this completes all of the changes necessary for the optimizer to handle loads and stores correctly.  I'm going to try and come up with some additional testing, though.

llvm-svn: 139533

llvm-svn: 136008

llvm-svn: 135904

size but different element types, so that it filters out the cases
that CreateShuffleVectorCast doesn't handle. This fixes rdar://9786827.

llvm-svn: 135721

llvm-svn: 135478

llvm-svn: 135375

llvm-svn: 134568

llvm-svn: 134549

llvm-svn: 134538

llvm-svn: 134235

alloca that only holds a copy of a global and we're going to replace the users
of the alloca with that global, just nuke the lifetime intrinsics. Part of
PR10121.

llvm-svn: 133905

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.

llvm-svn: 133338

alloca. Fixes part of <rdar://problem/9580800>.

llvm-svn: 133336

unless ScalarKind is Vector.

llvm-svn: 133335

llvm-svn: 132982

llvm-svn: 132952

llvm-svn: 132940

llvm-svn: 132939

llvm-svn: 132938

spartan right now, but I plan to encode more information in this enum to improve
the correctness and reliability of SRoA. At least this first pass makes it
possible to make VectorTy an actual VectorType.

llvm-svn: 132937

llvm-svn: 132936

llvm-svn: 132767

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.

llvm-svn: 132766

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.

llvm-svn: 132759

llvm-svn: 132578

llvm-svn: 131956

promoting allocas to SSA variables. Fixes <rdar://problem/9479036>.

llvm-svn: 131953

return the pointer being dereferenced, it returns the pointee, but a call
might return the pointer itself.

llvm-svn: 130979

generated by llvm-gcc, since llvm-gcc uses 2 i64s for passing a 4 x float
vector on ARM rather than an i64 array like Clang.

llvm-svn: 129878

delete it.

llvm-svn: 129877

more cases.

llvm-svn: 129876

llvm-svn: 129532

llvm-svn: 129509