llvm-svn: 185987

functions. Make the function attributes pass add it to known library functions
and when it can deduce it.

llvm-svn: 185735

Now the two possible uses of not are
* not cmd
  Will return true if cmd doesn't crash and returns false.
* not --crash cmd
  Will return true if cmd crashes.

It will be used/tested in a followup commit for the clang crash recovery
testing.

llvm-svn: 185678

Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid specifying the vector size.

llvm-svn: 185606

algorithm when assigning EnumValues to the synthesized registers.

The current algorithm, LessRecord, uses the StringRef compare_numeric
function.  This function compares strings, while handling embedded numbers.
For example, the R600 backend registers are sorted as follows:

  T1
  T1_W
  T1_X
  T1_XYZW
  T1_Y
  T1_Z
  T2
  T2_W
  T2_X
  T2_XYZW
  T2_Y
  T2_Z

In this example, the 'scaling factor' is dEnum/dN = 6 because T0, T1, T2
have an EnumValue offset of 6 from one another.  However, in other parts
of the register bank, the scaling factors are different:

dEnum/dN = 5:
  KC0_128_W
  KC0_128_X
  KC0_128_XYZW
  KC0_128_Y
  KC0_128_Z
  KC0_129_W
  KC0_129_X
  KC0_129_XYZW
  KC0_129_Y
  KC0_129_Z

The diff lists do not work correctly because different kinds of registers have
different 'scaling factors'.  This new algorithm, LessRecordRegister, tries to
enforce a scaling factor of 1.  For example, the registers are now sorted as
follows:

  T1
  T2
  T3
  ...
  T0_W
  T1_W
  T2_W
  ...
  T0_X
  T1_X
  T2_X
  ...
  KC0_128_W
  KC0_129_W
  KC0_130_W
  ...

For the Mips and R600 I see a 19% and 6% reduction in size, respectively.  I
did see a few small regressions, but the differences were on the order of a
few bytes (e.g., AArch64 was 16 bytes).  I suspect there will be even
greater wins for targets with larger register files.

Patch reviewed by Jakob.
rdar://14006013

llvm-svn: 185094

This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.

In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.

For example, if you have an instruction like:

def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;

You can look up the operand indices using the new function, like this:

Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst)  => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2

The operand names are case sensitive, so $dst and $DST are considered
different operands.

This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values.  These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.

llvm-svn: 184879

llvm-svn: 184826

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