llvm-svn: 117418

memory, so a MachineMemOperand is useful (not propagated
into the MachineInstr yet).  No functional change except
for dump output.

llvm-svn: 117413

llvm-svn: 117411

explicit about the operands. Split out the different variants into separate
instructions. This gives us the ability to, among other things, assign
different scheduling itineraries to the variants. rdar://8477752.

llvm-svn: 117409

llvm-svn: 117402

llvm-svn: 117398

llvm-svn: 117394

llvm-svn: 117388

llvm-svn: 117387

llvm-svn: 117380

llvm-svn: 117378

llvm-svn: 117374

on RIP relative relocations looks artificial, but this is a superset of
what we were able to do before.

llvm-svn: 117364

The SPU ABI does not mention v64, and all examples
in C suggest v128 are treated similarily to arrays, 
we use array alignment for v64 too. This makes the 
alignment of e.g. [2 x <2 x i32>] behave "intuitively"
and similar to as if the elements were e.g. i32s.

This also makes an "unaligned store" test to be 
aligned, with different (but functionally equivalent)
code generated.

llvm-svn: 117360

llvm-svn: 117348

llvm-svn: 117347

llvm-svn: 117331

the existing streamer methods that are endian safe.

llvm-svn: 117323

cannot use tailcall.  PR 8461.

llvm-svn: 117322

llvm-svn: 117315

llvm-svn: 117309

Attempt to provide correct encodings for NEON vbit and vbif, even though we can't test them at the moment.

llvm-svn: 117294

llvm-svn: 117293

llvm-svn: 117291

llvm-svn: 117282

llvm-svn: 117280

llvm-svn: 117279

llvm-svn: 117276

llvm-svn: 117275

llvm-svn: 117274

llvm-svn: 117273

we check for _GLOBAL_OFFSET_TABLE_.

llvm-svn: 117241

note that we can actually handle some f64 arguments.

llvm-svn: 117209

llvm-svn: 117206

llvm-svn: 117205

name and prefixed with 'LLVM_'.

llvm-svn: 117203

llvm-svn: 117202

until other LLVM projects using these are cleaned up.

llvm-svn: 117200

llvm-svn: 117194

llvm-svn: 117192