llvm-svn: 178083

llvm-svn: 178082

All Intel CPUs since Yonah look a lot alike, at least at the granularity
of the scheduling models. We can add more accurate models for
processors that aren't Sandy Bridge if required. Haswell will probably
need its own.

The Atom processor and anything based on NetBurst is completely
different. So are the non-Intel chips.

llvm-svn: 178080

Now all x86 instructions that have itinerary classes also have SchedRW
lists. This is required before the new scheduling models can be used.

There are still unannotated instructions remaining, but they don't have
itinerary classes either.

llvm-svn: 178051

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

llvm-svn: 178050

This could definitely be more granular. I am not sure if it makes a
difference.

llvm-svn: 178049

llvm-svn: 178048

- Add 'PRFCHW' feature defined in AVX2 ISA extension

llvm-svn: 178040

- It's still considered aligned when the specified alignment is larger
  than the natural alignment;
- The new alignment for the high 128-bit vector should be min(16,
  alignment) as the pointer is advanced by 16, a power-of-2 offset.

llvm-svn: 177947

The model isn't hooked up by this patch because the instruction set
isn't fully annotated yet.

llvm-svn: 177942

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

llvm-svn: 177936

llvm-svn: 177935

llvm-svn: 177910

llvm-svn: 177909

llvm-svn: 177888

This fixes Apple bug: 13493622

llvm-svn: 177887

llvm-svn: 177611

It's not yet clear if these instructions need a more careful model.

llvm-svn: 177599

This is used for all the expensive system instructions.

llvm-svn: 177598

llvm-svn: 177592

llvm-svn: 177591

- After moving logic recognizing vector shift with scalar amount from
  DAG combining into DAG lowering, we declare to customize all vector
  shifts even vector shift on AVX is legal. As a result, the cost model
  needs special tuning to identify these legal cases.

llvm-svn: 177586

llvm-svn: 177540

llvm-svn: 177539

- Move SRA/SRL/SHL lowering support from DAG combination to DAG lowering
  to support extended 256-bit integer in AVX but not AVX2.

llvm-svn: 177478

- Prepare moving logic from DAG combining into DAG lowering. There's no
  functionality change.

llvm-svn: 177477

- no functionality change

llvm-svn: 177476

llvm-svn: 177461

llvm-svn: 177460

llvm-svn: 177459

logic as a QOI cleanup.  No functional change.  Tests already in place.
rdar://13456414

llvm-svn: 177446

Add a new WriteZero SchedWrite type for the common dependency-breaking
instructions that clear a register.

llvm-svn: 177442

an X86Operand, but also performs a Sema lookup and adds the sizing directive
when appropriate.  Use this when parsing a bracketed statement.  This is
necessary to get the instruction matching correct as well.  Test case coming
on clang side.
rdar://13455408

llvm-svn: 177439

  def : Pat<(load (i64 (X86Wrapper tglobaltlsaddr :$dst))),
            (MOV64rm tglobaltlsaddr :$dst)>;

This pattern is invalid because the MOV64rm instruction expects a
source operand of type "i64mem", which is a subclass of X86MemOperand
and thus actually consists of five MI operands, but the Pat provides
only a single MI operand ("tglobaltlsaddr" matches an SDnode of
type ISD::TargetGlobalTLSAddress and provides a single output).

Thus, if the pattern were ever matched, subsequent uses of the MOV64rm
instruction pattern would access uninitialized memory.  In addition,
with the TableGen patch I'm about to check in, this would actually be
reported as a build-time error.

Fortunately, the pattern does in fact never match, for at least two
independent reasons.

First, the code generator actually never generates a pattern of the
form (load (X86Wrapper (tglobaltlsaddr))).  For most combinations of
TLS and code models, (tglobaltlsaddr) represents just an offset that
needs to be added to some base register, so it is never directly
dereferenced.  The only exception is the initial-exec model, where
(tglobaltlsaddr) refers to the (pc-relative) address of a GOT slot,
which *is* in fact directly dereferenced: but in that case, the
X86WrapperRIP node is used, not X86Wrapper, so the Pat doesn't match.

Second, even if some patterns along those lines *were* ever generated,
we should not need an extra Pat pattern to match it.  Instead, the
original MOV64rm instruction pattern ought to match directly, since
it uses an "addr" operand, which is implemented via the SelectAddr
C++ routine; this routine is supposed to accept the full range of
input DAGs that may be implemented by a single mov instruction,
including those cases involving ISD::TargetGlobalTLSAddress (and
actually does so e.g. in the initial-exec case as above).

To avoid build breaks (due to the above-mentioned error) after the
TableGen patch is checked in, I'm removing this Pat here.

llvm-svn: 177426

Patch by Ahmad, Muhammad T <muhammad.t.ahmad@intel.com>

llvm-svn: 177421

llvm-svn: 177418

llvm-svn: 177417

logic as a QOI cleanup.
rdar://13445327

llvm-svn: 177413

parsed one.  Test case coming shortly.
rdar://13446980

llvm-svn: 177347