shift-by-1 instructions, where the asmstring doesn't contain
the implicit 1.  It turns out that a bunch of these rotate
instructions were completely broken because they used 1 
instead of $1.

This fixes assembly mismatches on "rclb	$1, %bl" and friends,
where we used to generate the 3 byte form, we now generate the
proper 2-byte form.

llvm-svn: 118355

listed in its asm string, for consistency with the other similar
instructions.

llvm-svn: 118354

llvm-svn: 118353

fixed physical registers.  Start moving fp comparison
aliases to the .td file (which default to using %st1 if
nothing is specified).

llvm-svn: 118352

(surprise!) a list of registers. Register lists are consecutive, so we only need
to record the start register plus the number of registers.

llvm-svn: 118351

add fixed immediate values.  Move the aad and aam aliases to
use this, and document it.

llvm-svn: 118350

llvm-svn: 118349

llvm-svn: 118348

llvm-svn: 118347

floating point stack instructions instead of looking for b/w/l/q.

This fixes issues where we'd accidentally match fistp to fistpl,
when it is in fact an ambiguous instruction.

This changes the behavior of llvm-mc to reject fstp, which was the
correct fix for rdar://8456389:
t.s:1:1: error: ambiguous instructions require an explicit suffix (could be 'fstps', 'fstpl', or 'fstpt')
fstp	(%rax)

it also causes us to correctly reject fistp and fist, which addresses
PR8528:

t.s:2:1: error: ambiguous instructions require an explicit suffix (could be 'fistps', or 'fistpl')
fistp (%rax)
^
t.s:3:1: error: ambiguous instructions require an explicit suffix (could be 'fists', or 'fistl')
fist (%rax)
^

Thanks to Ismail Donmez for tracking down the issue here!

llvm-svn: 118346

llvm-svn: 118342

llvm-svn: 118341

llvm-svn: 118340

llvm-svn: 118339

while the latter doesn't.

llvm-svn: 118338

llvm-svn: 118337

result instruction operand numbering matched the result pattern.

Fixing this allows us to move the xchg/test aliases to the .td file.

llvm-svn: 118334

Fixes 8559.

llvm-svn: 118333

llvm-svn: 118332

tidy up the movsx and movzx aliases.

llvm-svn: 118331

from c++ hacks to proper .td InstAlias definitions.  Change them!

llvm-svn: 118330

operand list instead of the operand list redundantly declared on the alias
or instruction.

With this change, we finally remove the ins/outs list on the alias.  Before:
  def : InstAlias<(outs GR16:$dst), (ins GR8 :$src),
                  "movsx $src, $dst",
                  (MOVSX16rr8W GR16:$dst, GR8:$src)>;
After:
  def : InstAlias<"movsx $src, $dst",
                  (MOVSX16rr8W GR16:$dst, GR8:$src)>;

This also makes the alias mechanism more general and powerful, which will
be exploited in subsequent patches.

llvm-svn: 118329

llvm-svn: 118310

llvm-svn: 118309

llvm-svn: 118307

llvm-svn: 118304

llvm-svn: 118301

llvm-svn: 118300

llvm-svn: 118295

llvm-svn: 118294

llvm-svn: 118291

(relocations, e.g.), but this will allow simple things to flow through.

llvm-svn: 118289

llvm-svn: 118288

llvm-svn: 118287

llvm-svn: 118280

to perform the copy, which may be of lots of memory [*].  It would be good if the
fall-back code generated something reasonable, i.e. did the copy in a loop, rather
than vast numbers of loads and stores.  Add a note about this.  Currently target
specific code seems to always kick in so this is more of a theoretical issue rather
than a practical one now that X86 has been fixed.
[*] It's amazing how often people pass mega-byte long arrays by copy...

llvm-svn: 118275

llvm-svn: 118272

sequence of loads and stores was being generated to perform the
copy on the x86 targets if the parameter was less than 4 byte
aligned, causing llc to use up vast amounts of memory and time.
Use a "rep movs" form instead.  PR7170.

llvm-svn: 118260

llvm-svn: 118257

llvm-svn: 118254