For decoding, keep the current behavior of always decoding these as their REP
versions. In the future, this could be improved to recognize the cases where
these behave as XACQUIRE and XRELEASE and decode them as such.

llvm-svn: 184207

llvm-svn: 184164

And add Sandybridge/Haswell resource buffers.

llvm-svn: 184034

Replace the ill-defined MinLatency and ILPWindow properties with
with straightforward buffer sizes:
MCSchedMode::MicroOpBufferSize
MCProcResourceDesc::BufferSize

These can be used to more precisely model instruction execution if desired.

Disabled some misched tests temporarily. They'll be reenabled in a few commits.

llvm-svn: 184032

llvm-svn: 183941

llvm-svn: 183940

llvm-svn: 183928

It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.

llvm-svn: 183864

llvm-svn: 183690

PR16281.

llvm-svn: 183630

llvm-svn: 183509

llvm-svn: 183508

llvm-svn: 183465

The element passed to push_back is not copied before the vector reallocates.
The client needs to copy the element first before passing it to push_back.

No test case, will be tested by follow-up swift scheduler model change (it
segfaults without this change).

llvm-svn: 183459

llvm-svn: 183426

Don't output data if we are supposed to ignore the record.

Reapply of 183255, I don't think this was causing the tablegen segfault on linux
testers.

llvm-svn: 183311

This fixes some of the ridiculously complex code for optimizing the
machine model tables that are shared among all processors of a given
target. A9 and Swift both use the "special" feature that maps old
itinerary classes to new machine model defs. They map different
overlapping subsets of instructions, which wasn't handled correctly.

llvm-svn: 183302

llvm-svn: 183273

Don't output data if we are supposed to ignore the record.

llvm-svn: 183255

This also makes TableGen able to compute sizes/offsets of synthesized
indices representing tuples.

llvm-svn: 183061

NOTE: If this broke your out-of-tree backend, in *RegisterInfo.td, change
the instances of SubRegIndex that have a comps template arg to use the
ComposedSubRegIndex class instead.

In TableGen land, this adds Size and Offset attributes to SubRegIndex,
and the ComposedSubRegIndex class, for which the Size and Offset are
computed by TableGen. This also adds an accessor in MCRegisterInfo, and
Size/Offsets for the X86 and ARM subreg indices.

llvm-svn: 183020

llvm-svn: 182910

The size reduction in the RegDiffLists are rather dramatic.  Here are a few
size differences for MCTargetDesc.o files (before and after) in bytes:
R600 - 36160B - 11184B - 69% reduction
ARM - 28480B - 8368B - 71% reduction
Mips - 816B - 576B - 29% reduction

One side effect of dynamically computing the aliases is that the iterator does
not guarantee that the entries are ordered or that duplicates have been removed.
The documentation implies this is a safe assumption and I found no clients that
requires these attributes (i.e., strict ordering and uniqueness).

My local LNT tester results showed no execution-time failures or significant
compile-time regressions (i.e., beyond what I would consider noise) for -O0g,
-O2 and -O3 runs on x86_64 and i386 configurations.
rdar://12906217

llvm-svn: 182783

llvm-svn: 182761

llvm-svn: 182758

llvm-svn: 182715

Currently the fast-isel table generator recognizes registers, register
classes, and immediates for source pattern operands.  ValueType
operands are not recognized.  This is not a problem for existing
targets with fast-isel support, but will not work for targets like
PowerPC and SPARC that use types in source patterns.

The proposed patch allows ValueType operands and treats them in the
same manner as register classes.  There is no convenient way to map
from a ValueType to a register class, but there's no need to do so.
The table generator already requires that all types in the source
pattern be identical, and we know the register class of the output
operand already.  So we just assign that register class to any
ValueType operands we encounter.

No functional effect on existing targets.  Testing deferred until the
PowerPC target implements fast-isel.

llvm-svn: 182512

This lane mask provides information about which register lanes
completely cover super-registers. See the block comment before
getCoveringLanes().

llvm-svn: 182034

llvm-svn: 181930

llvm-svn: 181925

Refer to 'FileCheck.rst'f for details of 'CHECK-DAG'.

llvm-svn: 181827

llvm-svn: 181824

-DLLVM_ENABLE_THREADS=false.

llvm-svn: 181788

llvm-svn: 181418

llvm-svn: 181402

llvm-svn: 181371

This seemed like the cleanest way to find the test executable.  Also fix
the file mode.

llvm-svn: 180770

Handle tied sub-operands in AsmMatcherEmitter

The problem this patch addresses is the handling of register tie
constraints in AsmMatcherEmitter, where one operand is tied to a
sub-operand of another operand.  The typical scenario for this to
happen is the tie between the "write-back" register of a pre-inc
instruction, and the base register sub-operand of the memory address
operand of that instruction.

The current AsmMatcherEmitter code attempts to handle tied
operands by emitting the operand as usual first, and emitting
a CVT_Tied node when handling the second (tied) operand.  However,
this really only works correctly if the tied operand does not
have sub-operands (and isn't a sub-operand itself).  Under those
circumstances, a wrong MC operand list is generated.

In discussions with Jim Grosbach, it turned out that the MC operand
list really ought not to contain tied operands in the first place;
instead, it ought to consist of exactly those operands that are
named in the AsmString.  However, getting there requires significant
rework of (some) targets.

This patch fixes the immediate problem, and at the same time makes
one (small) step in the direction of the long-term solution, by
implementing two changes:

1. Restricts the AsmMatcherEmitter handling of tied operands to
   apply solely to simple operands (not complex operands or
   sub-operand of such).

This means that at least we don't get silently corrupt MC operand
lists as output.  However, if we do have tied sub-operands, they
would now no longer be handled at all, except for:

2. If we have an operand that does not occur in the AsmString,
   and also isn't handled as tied operand, simply emit a dummy
   MC operand (constant 0).

This works as long as target code never attempts to access
MC operands that do no not occur in the AsmString (and are
not tied simple operands), which happens to be the case for
all targets where this situation can occur (ARM and PowerPC).

[ Note that this change means that many of the ARM custom
  converters are now superfluous, since the implement the
  same "hack" now performed already by common code. ]

Longer term, we ought to fix targets to never access *any*
MC operand that does not occur in the AsmString (including
tied simple operands), and then finally completely remove
all such operands from the MC operand list.

Patch approved by Jim Grosbach.

llvm-svn: 180677

Thanks Chandler!

llvm-svn: 180592

It makes more sense to have git-svnup here than catting said file in the
documentation (where we should rather point users to this directory).
I included git-svnrevert as an additional gift to the community. I will update
the documentation in a second commit later today.

git-svnrevert takes in a git hash for a commit, looks up the svn revision for
said commit and then creates the normal git revert commit message with the one
liner message, except instead of saying

  Revert "<<<INSERT ONELINER HERE>>>"

  This reverts commit <<<INSERT GITHASH HERE>>>

It says:

  Revert "<<<INSERT ONELINER HERE>>>"

  This reverts commit r<<<INSERT SVN REVISION HERE>>>

so git hashes will not escape into our svn logs (which just look unseemly).

llvm-svn: 180587