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

llvm-svn: 94776

lowering. We'll either figure it out, or not and be lowered by
SelectionDAGBuild.

Add test.

llvm-svn: 94775

llvm-svn: 94771

llvm-svn: 94765

enhanced disassembler, and the necessary makefile
rules to build the table for X86.

llvm-svn: 94764

llvm-svn: 94763

"visit*" method is called, take the newly created nodes, walk them in a DFS
fashion, and if they don't have an ordering set, then give it one.

llvm-svn: 94757

llvm-svn: 94752

  getelementptr (i8* inttoptr (i64 1 to i8*), i32 -1) 
  to
  inttoptr (i64 0 to i8*)
from the VMCore constant folder. It didn't handle sign-extension properly
in the case where the source integer is smaller than a pointer size. And,
it relied on an assumption about sizeof(i8).

The Analysis constant folder still folds these kinds of things; it has
access to TargetData, so it can do them right.

Add a testcase which tests that the VMCore constant folder doesn't
miscompile this, and that the Analysis folder does fold it.

llvm-svn: 94750

llvm-svn: 94746