llvm-svn: 118342

llvm-svn: 118341

llvm-svn: 118340

llvm-svn: 118339

while the latter doesn't.

llvm-svn: 118338

llvm-svn: 118337

llvm-svn: 118335

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

  (someinst GR16:$foo, GR32:$foo)

Reimplement BuildAliasOperandReference to be correctly
based on the names of operands in the result pattern,
instead of on the instruction operand definitions.

llvm-svn: 118328

llvm-svn: 118327

llvm-svn: 118326

llvm-svn: 118325

file instead of the asmmatcher.

llvm-svn: 118324

llvm-svn: 118310

llvm-svn: 118309

llvm-svn: 118307

llvm-svn: 118304

llvm-svn: 118301

llvm-svn: 118300

llvm-svn: 118296

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: 118281

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

they do :-(

llvm-svn: 118250

llvm-svn: 118249