llvm-svn: 143895

llvm-svn: 143634

one aspect of them by having them use the (annoying, if not broken)
proper library dependency model for adding the LLVMTableGen library as
a dependency. This could manifest as a link order issue in the presence
of separate LLVM / Clang source builds with CMake and a linker that
really cares about such things.

Also, add the Support dependency to llvm-tblgen itself so that it
doesn't rely on TableGen's transitive Support dependency. A parallel
change for clang-tblgen will be forthcoming.

llvm-svn: 143531

For example,

On ARM, "mov r3, #-3" is an alias for "mvn r3, #2", so we want to use a
matcher pattern that handles the bitwise negation when mapping to t2MVNi.

llvm-svn: 143233

If the register class in the source alias is a subclass of the register class
of the actual instruction, the alias can still match OK since the constraints
are strictly a subset of what the instruction can actually handle.

llvm-svn: 143200

llvm-svn: 143153

llvm-svn: 142741

llvm-svn: 142726

llvm-svn: 142691

llvm-svn: 142682

llvm-svn: 142675

Next step in the ongoing saga of NEON load/store assmebly parsing. Handle
VLD1 instructions that take a two-register register list.

Adjust the instruction definitions to only have the single encoded register
as an operand. The super-register from the pseudo is kept as an implicit def,
so passes which come after pseudo-expansion still know that the instruction
defines the other subregs.

llvm-svn: 142670

llvm-svn: 142441

llvm-svn: 142356

llvm-svn: 142321

llvm-svn: 142303

NEON immediates are "interesting". Start of the work to handle parsing them
in an 'as' compatible manner. Getting the matcher to play nicely with
these and the floating point immediates from VFP is an extra fun wrinkle.

llvm-svn: 142293

Fix unused variable warning in the rare circumstance that we have no feature-dependent instructions.

llvm-svn: 142193

Shaves 200k off Release-Asserts clang binaries on i386.

llvm-svn: 142191

llvm-svn: 142141

llvm-svn: 142122

Add X86 INVPCID instruction. Add 32/64-bit predicates to INVEPT, INVVPID, VMREAD, and VMWRITE to remove hack from X86RecognizableInstr.

llvm-svn: 142117

Add X86 BEXTR instruction. This instruction uses VEX.vvvv to encode Operand 3 instead of Operand 2 so needs special casing in the disassembler and code emitter. Ultimately, should pass this information from tablegen

llvm-svn: 142105

Add support for X86 blsr, blsmsk, and blsi instructions. Required extra work because these are the first VEX encoded instructions to use the reg field as an opcode extension.

llvm-svn: 142082

llvm-svn: 141947

TableGen infers unmodeled side effects on instructions without a
pattern.  Fix some instruction definitions where that was overlooked.

Also raise an error if a rematerializable instruction has unmodeled side
effects. That doen't make any sense.

llvm-svn: 141929

llvm-svn: 141786

llvm-svn: 141699

Fix disassembling of popcntw. Also remove some code that says it accounts for 64BIT_REXW_XD not existing, but it does exist.

llvm-svn: 141642

This should unbreak the picky buildbots.

llvm-svn: 141575

The table is indexed by opcode, so simply removing pseudo-instructions
creates a wrong mapping from opcode to table entry.

Add a test case for xorps which has a very high opcode that exposes this
problem.

llvm-svn: 141562

llvm-svn: 141446

Revert part of r141274. Only need to change encoding for xchg %eax, %eax in 64-bit mode. This is because in 64-bit mode xchg %eax, %eax implies zeroing the upper 32-bits of RAX which makes it not a NOP. In 32-bit mode using NOP encoding is fine.

llvm-svn: 141353

llvm-svn: 141293

Fix assembling of xchg %eax, %eax to not use the NOP encoding of 0x90. This was done by creating a new register group that excludes AX registers. Fixes PR10345. Also added aliases for flipping the order of the operands of xchg <reg>, %eax.

llvm-svn: 141274

llvm-svn: 141266

This restores my karma after I added TRI::getSubClassWithSubReg().

Register constraints are applied 'backwards'.  Starting from the
register class required by an instruction operand, the correct question
is: 'How can I constrain the super-register register class so all its
sub-registers satisfy the instruction constraint?' The
getMatchingSuperRegClass() hook answers that.

We never need to go 'forwards': Starting from a super-register register
class, what register class are the sub-registers in?  The
getSubRegisterRegClass() hook did that.

llvm-svn: 141258

This function is used to constrain a register class to a sub-class that
supports the given sub-register index.

For example, getSubClassWithSubReg(GR32, sub_8bit) -> GR32_ABCD.

The function will be used to compute register classes when emitting
INSERT_SUBREG and EXTRACT_SUBREG nodes and for register class inflation
of sub-register operations.

The version provided by TableGen is usually adequate, but targets can
override.

llvm-svn: 141142

This should unbreak the Windows build.

llvm-svn: 141105

The set of register classes should be closed under sub-register
operations and intersections. That will allow the register allocator to
model combinations of constraints accurately.

This patch implements the easiest form of register class inference:  For
every register class, and for every sub-register SubIdx, the subset of
registers in RC that have a SubIdx sub-register should also be a register
class.

This does create some new register classes for the targets in the tree:

ARM gets a new QQQQPR_with_ssub_0.  This class was omitted from the .td
file on purpose because it only has two registers.  InstrEmitter and
RegisterCoalescer have safeguards against selecting too small register
classes, so it is harmless.

PowerPC gets a G8RC_with_sub_32 class because LR is not a sub_32
sub-register of LR8.  I think that might be an omission?

X86 puts RIP in the GR64 class, and since that register doesn't have
8-bit sub-registers, we get:

  GR64_with_sub_8bit
  GR64_TC_with_sub_8bit
  GR64_NOREX_with_sub_8bit
  GR64_TC_with_sub_8bit_hi

The various CodeGen classes have already been fixed so adding new
register classes should not affect compile time.

llvm-svn: 141084