it in with the SSSE3 instructions.

Steward! Could you place this chair by the aft sun deck? I'm trying to get away
from the Astors. They are such boors!

llvm-svn: 115552

Patch by Cameron!

llvm-svn: 115480

Based on the patch by Cameron Esfahani!

llvm-svn: 115479

llvm-svn: 115477

the immediate field of pshufw is actually an 8-bit field, not a 8-bit field that is sign extended.  This fixes PR8288

llvm-svn: 115473

so and also change X86 for consistency.

Investigating if this can be improved a bit.

llvm-svn: 115469

the right file.  The assembler supports all the 3dnow instructions now,
but not the "3dnowa" ones.

llvm-svn: 115468

llvm-svn: 115467

else in X86), and add support for pavgusb.  This is apparently the
only instruction (other than movsx) that is preventing ffmpeg from building
with clang.

If someone else is interested in banging out the rest of the 3DNow! 
instructions, it should be quite easy now.

llvm-svn: 115466

llvm-svn: 115429

backing int_x86_ssse3_pshuf_w got removed.  This caused PR8280.

llvm-svn: 115422

been MC-ized for assembly printing. MSP430 is mostly so, but still has the
asm printer and lowering code in the printer subdir for the moment.

llvm-svn: 115360

llvm-svn: 115311

The x86_mmx type is used for MMX intrinsics, parameters and
return values where these use MMX registers, and is also
supported in load, store, and bitcast.

Only the above operations generate MMX instructions, and optimizations
do not operate on or produce MMX intrinsics. 

MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into
smaller pieces.  Optimizations may occur on these forms and the
result casted back to x86_mmx, provided the result feeds into a
previous existing x86_mmx operation.

The point of all this is prevent optimizations from introducing
MMX operations, which is unsafe due to the EMMS problem.

llvm-svn: 115243

use MC instructions in the printInstruction() method via the tablegen flag
for it rather than a #define prior to including the autogenerated bits.

llvm-svn: 115238

llvm-svn: 115168

llvm-svn: 115156

llvm-svn: 115154

for the dwarf .loc support to emit dwarf line number tables.

llvm-svn: 115153

With this patch in

movq    $foo, foo(%rip)
foo:
.long   foo

We produce a R_X86_64_32S for the first relocation and R_X86_64_32 for the
second one.

llvm-svn: 115134

llvm-svn: 115100

  lib/Target/X86/X86MCCodeEmitter.cpp: 190: error: suggest parentheses around '&&' within '||'

llvm-svn: 115064

llvm-svn: 115061

llvm-svn: 115029

llvm-svn: 115027

order as cctools for diffability.

llvm-svn: 115022

are defined to emit the 0x67 prefix byte.  rdar://8482675

llvm-svn: 115021

operands.

With this done, we can remove the _Int suffixes from the round instructions
without the disassembler blowing up.  This allows the assembler to support
them, implementing rdar://8456376 - llvm-mc rejects 'roundss'

llvm-svn: 115019

Clean up cvttps2dq by removing some redundant implementations of the
same instruction.  rdar://8456382

llvm-svn: 115018

llvm-svn: 115017

an instruction that requires a WHOLE NEW wonderful kind of alias.

llvm-svn: 115015

MCStreamer to emit into instead of an MCInst to fill in.  This allows the
matcher extra flexibility and is more convenient.

llvm-svn: 115014

llvm-svn: 114844

llvm-svn: 114822

llvm-svn: 114821

llvm-svn: 114819

My previous fix for rdar://8456371 should only apply to fmulp/faddp,
not to fmul/fadd.  Instruction set orthogonality is overrated or 
something.

llvm-svn: 114818

llvm-svn: 114815

llvm-svn: 114811

but balrog was wanting it on irc.

llvm-svn: 114809