something totally broken and parsing them as immediates, but the .td file also
had the wrong match class so things sortof worked. Except, that is, that we
would parse
  movl $0, %eax
as
  movl 0, %eax
Feel free to guess how well that worked.

llvm-svn: 94869

in the order they were declared.

llvm-svn: 94868

llvm-svn: 94866

llvm-svn: 94863

needed for this test, but otherwise, there's nothing ARM-specific about
it and no need to specify the calling convention.

llvm-svn: 94862

llvm-svn: 94861

line. Turns out edit_distance can be slow if the string we are scanning for
happens to be quite large.

llvm-svn: 94860

register, and use to cleanup a FIXME in X86AsmParser.cpp.

llvm-svn: 94859

This bug was exposed by my inliner cost changes in r94615, and caused failures
of lencod on most architectures when building with LTO.

This patch fixes lencod and 464.h264ref on x86-64 (and likely others).

llvm-svn: 94858

 - This test case is auto generated, and has been verified to round-trip
   correctly through llvm-mc by checking the assembled .o file before and after
   piping through llvm-mc. It will be extended over time as the matcher grows
   support for more instructions.

llvm-svn: 94857

bit (Inst{22}) and the M bit (Inst{5}) should be left unspecified.  For binary
format instructions, Inst{6} and Inst{4} need to specified for proper decodings.

llvm-svn: 94855

them from values that are not actually defined in the module.

llvm-svn: 94854

llvm-svn: 94853

create a testcase where this matters.  The select+load transformation only
occurs when isSafeToLoadUnconditionally is true, and in those situations,
instcombine also changes the underlying objects to be aligned.  This seems
like a good idea regardless, and I've verified that it doesn't pessimize
the subsequent realignment.

llvm-svn: 94850

llvm-svn: 94848

Before:

<stdin>:94:1: note: possible intended match here
 movsd 4096(%rsi), %xmm0
^

After:
<stdin>:94:2: note: possible intended match here
 movsd 4096(%rsi), %xmm0
 ^

llvm-svn: 94847

Before:

test/CodeGen/X86/lsr-reuse.ll:52:34: error: expected string not found in input
; CHECK: movsd -2048(%rsi), %xmm0
                                 ^

After:

test/CodeGen/X86/lsr-reuse.ll:52:10: error: expected string not found in input
; CHECK: movsd -2048(%rsi), %xmm0
         ^

llvm-svn: 94846

Make sure the size is doubled (not 4x).

llvm-svn: 94845

the library.

llvm-svn: 94844

llvm-svn: 94843

We were not writing bitcode for function-local metadata whose operands have been erased (making it not have any more function-local operands)

llvm-svn: 94842

llvm-svn: 94841

that loads its contents lazily from bitcode.  I think these are the
only remaining mis-named functions.

llvm-svn: 94840

llvm-svn: 94835

indices are safe if the result is known to be within the bounds of the
underlying object.

llvm-svn: 94829

llvm-svn: 94825

llvm-svn: 94822

Before inserting   llvm.dbg.declare intrinsic at the end of a basic block, check whether the basic block has a terminator or not.
This API is used by clang and the test case is test/CodeGen/debug-info-crash.c in clang module.

llvm-svn: 94820

llvm-svn: 94809

llvm-svn: 94808

llvm-svn: 94807

llvm-svn: 94805

llvm-svn: 94804

(via APInt &RHSKnownZero = KnownZero, etc) seems dangerous and confusing to me: it
is easy not to notice this, and then wonder why KnownZero/RHSKnownZero changed
underneath you when you modified RHSKnownZero/KnownZero etc.  So get rid of this.
No intended functionality change (tested with "make check" + llvm-gcc bootstrap).

llvm-svn: 94802

(fix for PR6165) are needed here too.

llvm-svn: 94801

 - Thanks Doug, who is obviously less lazy than me!

llvm-svn: 94795

llvm-svn: 94783

disassembly information have a better comment (and
better guard macros).

llvm-svn: 94781

library as a static and a shared library.  Added dependencies
so the target-specific enhanced disassembly info tables are
built before the library.

llvm-svn: 94780

llvm-svn: 94777