Give it the right register format so we can also emit it when AVX is enabled.

llvm-svn: 183971

a somewhat randomly chosen cpu that will minimize cpu specific
differences on bots.

llvm-svn: 181814

It's causing failures on the atom bot.

llvm-svn: 181812

Patch by Andrea DiBiagio.

llvm-svn: 181809

This only covers the instructions that were given itinerary classes for
the Atom model.

llvm-svn: 178050

All the instructions tagged with IIC_DEFAULT had nothing in common, and
we already have a NoItineraries class to represent untagged
instructions.

llvm-svn: 177937

We used to generate a store (movq) + a load.
Now we use movd.

rdar://9946746

llvm-svn: 167056

- Add 'UseSSEx' to force SSE legacy insn not being selected when AVX is
  enabled.

  As the penalty of inter-mixing SSE and AVX instructions, we need
  prevent SSE legacy insn from being generated except explicitly
  specified through some intrinsics. For patterns supported by both
  SSE and AVX, so far, we force AVX insn will be tried first relying on
  AddedComplexity or position in td file. It's error-prone and
  introduces bugs accidentally.

  'UseSSEx' is disabled when AVX is turned on. For SSE insns inherited
  by AVX, we need this predicate to force VEX encoding or SSE legacy
  encoding only.

  For insns not inherited by AVX, we still use the previous predicates,
  i.e. 'HasSSEx'. So far, these insns fall into the following
  categories:
  * SSE insns with MMX operands
  * SSE insns with GPR/MEM operands only (xFENCE, PREFETCH, CLFLUSH,
    CRC, and etc.)
  * SSE4A insns.
  * MMX insns.
  * x87 insns added by SSE.

2 test cases are modified:

 - test/CodeGen/X86/fast-isel-x86-64.ll
   AVX code generation is different from SSE one. 'vcvtsi2sdq' cannot be
   selected by fast-isel due to complicated pattern and fast-isel
   fallback to materialize it from constant pool.

 - test/CodeGen/X86/widen_load-1.ll
   AVX code generation is different from SSE one after fixing SSE/AVX
   inter-mixing. Exec-domain fixing prefers 'vmovapd' instead of
   'vmovaps'.

llvm-svn: 162919

Remove the LowerMMXCONCAT_VECTORS function. It could never execute because there are no legal 64-bit vector types that could be used as inputs to a 128-bit concat_vectors. Remove a target specific SDNode and its patterns that become unused as a result.

llvm-svn: 161742

llvm-svn: 160941

llvm-svn: 156615

Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore.

llvm-svn: 150878

Adds an instruction itinerary to all x86 instructions, giving each a default latency of 1, using the InstrItinClass IIC_DEFAULT.

Sets specific latencies for Atom for the instructions in files X86InstrCMovSetCC.td, X86InstrArithmetic.td, X86InstrControl.td, and X86InstrShiftRotate.td. The Atom latencies for the remainder of the x86 instructions will be set in subsequent patches.

Adds a test to verify that the scheduler is working.

Also changes the scheduling preference to "Hybrid" for i386 Atom, while leaving x86_64 as ILP.

Patch by Preston Gurd!

llvm-svn: 149558

Instruction selection priority fixes to remove the XMM/XMMInt/orAVX predicates. Another commit will remove orAVX functions from X86SubTarget.

llvm-svn: 147841

Don't disable MMX support when AVX is enabled. Fix predicates for MMX instructions that were added along with SSE instructions to check for AVX in addition to SSE level.

llvm-svn: 147762

No test because I can't think of any way to write one that won't break quickly.

llvm-svn: 130932

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

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

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

llvm-svn: 115468

llvm-svn: 115429

backing int_x86_ssse3_pshuf_w got removed.  This caused PR8280.

llvm-svn: 115422

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

llvm-svn: 113501

uses MMX, even if it also uses other things) from InstrSSE
into InstrMMX.  No (intended) functional change.

llvm-svn: 113462

llvm-svn: 113420

llvm-svn: 113406

Omission of memory form of PI2PD is intentional; this
does not use an MMX register and does not put the chip
into MMX mode (PI2PS, oddly enough, does).
Operands of PI2PS follow the gcc builtin, not Intel.

llvm-svn: 113388

Enable palignr intrinsic.
These may need adjustment for a new VT in due course.

llvm-svn: 113233

this fixes rdar://8192860.  Unfortunately it can only be triggered
with llc because llvm-mc matches another (correctly encoded) version
of this, so no testcase.

llvm-svn: 108454

llvm-svn: 107610

llvm-svn: 104552

have a pattern and it had an invalid encoding.

llvm-svn: 104244

mm to mm/m64 and the Move quadword from xmm2/mem64 to xmm1 had the incorrect
encodings.

llvm-svn: 102952

llvm-svn: 102199

llvm-svn: 99748

llvm-svn: 98531

pattern which is broken (source and address swapped).

llvm-svn: 97958

llvm-svn: 97348

then use it as an MMX register (!?).

llvm-svn: 96901

don't alis it in the MMX .td file with a different width,
split into two X86ISD opcodes.  This fixes an x86 testcase.

llvm-svn: 96859