offset for stack references. Make sure we take that into account when
deciding whether to reserver an emergency spill slot for the register
scavenger. rdar://8559625

llvm-svn: 116714

llvm-svn: 116712

The old algorithm inserted a 'rotqmbyi' instruction which was
both redundant and wrong - it made shufb select bytes from the
wrong end of the input quad.

llvm-svn: 116701

working just fine.

llvm-svn: 116698

llvm-svn: 116694

special case handling for ARM::SP.

llvm-svn: 116688

llvm-svn: 116683

llvm-svn: 116681

llvm-svn: 116680

llvm-svn: 116679

more in the post-passes.

llvm-svn: 116678

single object format can be shared.

This also adds support for

mov zed+(bar-foo), %eax

on ELF and COFF targets.

llvm-svn: 116675

if any floating point arguments are passed to an external function.

llvm-svn: 116665

llvm-svn: 116653

ARMCodeEmitter::emitMiscInstruction!

llvm-svn: 116644

llvm-svn: 116640

llvm-svn: 116635

llvm-svn: 116628

llvm-svn: 116625

llvm-svn: 116622

llvm-svn: 116612

llvm-svn: 116604

scheduler may reorder loads from them before the stores and other such
badness. PR8347. Patch by David Meyer

llvm-svn: 116602

llvm-svn: 116601

llvm-svn: 116594

an explicit def. Make sure to capture that properly. rdar://8556556

llvm-svn: 116591

llvm-svn: 116588

llvm-svn: 116566

have been printed with the "S" modifier after the predicate.  With ARM's
unified syntax, they are supposed to go in the other order.  We fixed this
for Thumb when we switched to unified syntax but missed changing it for
ARM.  Apparently we don't generate these instructions often because no one
noticed until now.  Thanks to Bill Wendling for the testcase!

llvm-svn: 116563

llvm-svn: 116560

llvm-svn: 116537

and let the ARMExpandPseudoInsts pass fix them up into the real (MOVs)
instruction form.

llvm-svn: 116534

pseudonym.

llvm-svn: 116512

llvm-svn: 116498

llvm-svn: 116488

creates a cyclic dependency that breaks the build when
BUILD_SHARED_LIBS=ON

llvm-svn: 116480

GEP + alloca.

llvm-svn: 116474

here. The f32 in FCONSTS is handled as a double instead of a float in the
code. So the encoding of the immediate into the instruction isn't exactly in
line with the documentation in that regard. But given that we know it's handled
as a double, it doesn't cause any harm.

llvm-svn: 116471

llvm-svn: 116466

- Add missing patterns for some multiply add/subtract instructions.
- Add encodings for VMRS and VMSR.

llvm-svn: 116464