(yet) recognize the 'trap' mnemonic, so we use .short/.long to emit the
opcode directly. On Darwin, however, we do want the mnemonic for more
readable assembly code and better disassembly.

Adjust the .td file to use the 'trap' mnemonic and handle using the binutils
workaround in the assembly printer. Also tweak the formatting of the opcode
values to make them consistent between the MC printer and the old printer.

llvm-svn: 114679

llvm-svn: 114676

but the first one. Those will never be executed. There was logic to do this
but it was faulty.

llvm-svn: 114632

new VariantKind to the MCSymbolExpr seems like overkill, but I'm not sure
there's a more straightforward way to get the printing difference captured.
(i.e., x86 uses @PLT, ARM uses (PLT)).

llvm-svn: 114613

llvm-svn: 114601

CombineTo to avoid putting the result on the worklist.  I don't think it makes
much difference for now, but it might help someday as we add more DAG
combine optimizations.

llvm-svn: 114595

of those.  Refactor to share code for handling BUILD_VECTOR(VMOVRRD).
I don't have a testcase that exercises this, but it seems like an obvious
good thing to do.

llvm-svn: 114589

llvm-svn: 114578

llvm-svn: 114576

llvm-svn: 114563

llvm-svn: 114555

llvm-svn: 114553

llvm-svn: 114550

OptimizeCompareInstr should avoid iterating pass the beginning of the MBB when the 'and' instruction is after the comparison.

llvm-svn: 114506

the rest of it is next up.

llvm-svn: 114500

irrelevant, but add a new test for the new, improved functionality.

llvm-svn: 114494

passed the root of the match, even though only a few patterns
actually needed this (one in X86, several in ARM [which should
be refactored anyway], and some in CellSPU that I don't feel 
like detangling).   Instead of requiring all ComplexPatterns to
take the dead root, have targets opt into getting the root by
putting SDNPWantRoot on the ComplexPattern.

llvm-svn: 114471

llvm-svn: 114463

and store intrinsics are represented with MemIntrinsicSDNodes.

llvm-svn: 114454

llvm-svn: 114445

I am unable to write a test for this case, help is solicited, though...
What I did is to tickle the code in the debugger and verify that we do the right thing.

llvm-svn: 114430

into OptimizeCompareInstr.
This necessitates the passing of CmpValue around,
so widen the virtual functions to accomodate.

No functionality changes.

llvm-svn: 114428

llvm-svn: 114410

instead of srcvalue/offset pairs.  This corrects SV info for mem 
operations whose size is > 32-bits.

llvm-svn: 114401

llvm-svn: 114391

between the high and low registers for prologue/epilogue code. This was
a Darwin-only thing that wasn't providing a realistic benefit anymore.
Combining the save areas simplifies the compiler code and results in better
ARM/Thumb2 codegen.

For example, previously we would generate code like:
        push    {r4, r5, r6, r7, lr}
        add     r7, sp, #12
        stmdb   sp!, {r8, r10, r11}
With this change, we combine the register saves and generate:
        push    {r4, r5, r6, r7, r8, r10, r11, lr}
        add     r7, sp, #12

rdar://8445635

llvm-svn: 114340

llvm-svn: 114292

llvm-svn: 114263

thumb with floating point.

llvm-svn: 114256

llvm-svn: 114254

instructions (PICADD, PICLDR, et.al.)

llvm-svn: 114243

with one in the generic printing code is an error.

llvm-svn: 114242

llvm-svn: 114240

llvm-svn: 114237

value should be in GPRs when it's going to be used as a scalar, and we use
VMOVRRD to make that happen, but if the value is converted back to a vector
we need to fold to a simple bit_convert.  Radar 8407927.

llvm-svn: 114233

and shift instructions on ARM. Update the tests to match.

llvm-svn: 114230

llvm-svn: 114226

llvm-svn: 114215

llvm-svn: 114212

llvm-svn: 114195