(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

llvm-svn: 114597

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

needs to happen for darwin.

llvm-svn: 114577

llvm-svn: 114576

llvm-svn: 114563

llvm-svn: 114555

ARM cross-compiler on x86, because the MMO size did not match the type size.
This fixes the MMO size and also the size of the stack object to match the
type size.

llvm-svn: 114554

llvm-svn: 114553

llvm-svn: 114550

llvm-svn: 114536

x86-32: 32-bit calls were named "call" not "calll".  64-bit calls were correctly
named "callq", so this only impacted x86-32.

This fixes rdar://8456370 - llvm-mc rejects 'calll'

This also exposes that mingw/64 is generating a 32-bit call instead of a 64-bit call,
I will file a bugzilla.

llvm-svn: 114534

Teaching the code generator about CR8-15, how to rex them up, etc.

llvm-svn: 114533

llvm-svn: 114531

llvm-svn: 114529

llvm-svn: 114528

-This line, and those below, will be ignored--

M    test/MC/AsmParser/X86/x86_instructions.s
M    lib/Target/X86/AsmParser/X86AsmParser.cpp

llvm-svn: 114527

llvm-svn: 114526

llvm-svn: 114523

can access the stack due to how it is generated though.

llvm-svn: 114522

used with stack slots, but hey, lets be safe.

llvm-svn: 114521

llvm-svn: 114515

call through gs-relative memory now.

llvm-svn: 114510

llvm-svn: 114508

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

by having X86DAGToDAGISel::SelectAddr get passed in the parent node
of the operand match (the load/store/atomic op) and having it get
the address space from that, instead of having special FS/GS addr
mode operations that require duplicating the entire instruction set
to support.

This makes FS and GS relative accesses *far* more predictable and
work much better.  It also simplifies the X86 backend a bit, more
to come.

There is still a pending issue with nodes like ISD::PREFETCH and
X86ISD::FLD, which really should be MemSDNode's but aren't.

llvm-svn: 114491

the predicate to discover the number of sign bits.  Enhance X86's target lowering to provide
a useful response to this query.

llvm-svn: 114473

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: 114468

llvm-svn: 114463

llvm-svn: 114461

(sbbl x, x) sets the registers to 0 or ~0.  Combined with two's complement arithmetic, we can fold
the intermediate AND and the ADD into a single SUB.

This fixes <rdar://problem/8449754>.

llvm-svn: 114460