llvm-svn: 128183

llvm-svn: 128182

I'm backing this out for the second time. It was supposed to be fixed by r128164, but the mingw self-host must be defeating the fix.

llvm-svn: 128181

int tries = INT_MAX;    
while (tries > 0) {
      tries--;
}

The check should be:
        subs    r4, #1
        cmp     r4, #0
        bgt     LBB0_1

The subs can set the overflow V bit when r4 is INT_MAX+1 (which loop
canonicalization apparently does in this case). cmp #0 would have cleared
it while not changing the N and Z bits. Since BGT is dependent on the V
bit, i.e. (N == V) && !Z, it is not safe to eliminate the cmp #0.

rdar://9172742

llvm-svn: 128179

Also cleaning up some duplicated code while I'm here.

llvm-svn: 128176

(target-specific branchless method for double-width relational comparisons on x86)

llvm-svn: 128175

llvm-svn: 128173

This fixes 464.h264ref with the integrated assembler.

llvm-svn: 128172

The ExecutionEngine constructor already added the module, so there's no
need to call addModule() directly. Doing so causes a double-free of the
Module at program termination.

llvm-svn: 128171

Fix a bug introduced by my patch yesterday: BL is a 4-byte instructions like BLX, rather than a 2-byte instruction like B.

llvm-svn: 128169

so the scheduler can't create new interferences on the copies
themselves. Prior to this fix the scheduler could get stuck in a loop
creating copies.
Fixes PR9509.

llvm-svn: 128164

llvm-svn: 128163

llvm-svn: 128161

llvm-svn: 128160

Each of these instructions may have a RegsClobberInsn entry that can't be
ignored. Consecutive ranges are coalesced later when DwarfDebug::emitDebugLoc
merges entries.

llvm-svn: 128155

X86. Fixes PR9533.

llvm-svn: 128154

- Fix bug in ADDRrr/ADDRri/ADDRii selection for 64-bit addresses
- Add comparison selection for i64
- Add zext selection for i32 -> i64
- Add shl/shr/sha support for i64

llvm-svn: 128153

llvm-svn: 128149

that were hit in practice.

llvm-svn: 128146

The register allocator needs to know when the range shrinks.

llvm-svn: 128145

Empty ranges may represent undef values.

llvm-svn: 128144

llvm-svn: 128143

A global variable with internal linkage where all uses are in one function and whose address is never taken is a non-escaping local object and can't alias anything else.

llvm-svn: 128140

I'm tired of doing this manually for each checkout.
If anyone knows a better way debug isel for non-trivial tests feel
free to revert and let me know how to do it.

llvm-svn: 128132

kind, and fix serialization/deserialization of IdentifierInfo
attributes. These are requires for the new 'availability' attribute.

llvm-svn: 128130

Change inspired by llvm-bug 9530 submitted by Jyun-Yan You.

llvm-svn: 128122

A8.6.292 VCMPE

llvm-svn: 128120

llvm-svn: 128119

This fixes kimwitu++, bullet, and tramp3dv4 with the ARM integrated assembler.
Fixes <rdar://problem/9165738>.

llvm-svn: 128117

This will extend the ranges of debug info variables in registers until they are
clobbered.

Fix 1: Don't mistake DBG_VALUE instructions referring to incoming arguments on
the stack with DBG_VALUE instructions referring to variables in the frame
pointer. This fixes the gdb test-suite failure.

Fix 2: Don't trace through copies to physical registers setting up call
arguments. These registers are call clobbered, and the source register is more
likely to be a callee-saved register that can be extended through the call
instruction.

llvm-svn: 128114

We now tag them as IndexModePost.

This fixed http://llvm.org/bugs/show_bug.cgi?id=9530.

llvm-svn: 128113

llvm-svn: 128112

memory and writing it back to disk.

llvm-svn: 128108

llvm-svn: 128107

llvm-svn: 128106

VFP Load/Store Multiple Instructions used to embed the IA/DB addressing mode within the
MC instruction; that has been changed so that now, for example, VSTMDDB_UPD and VSTMDIA_UPD
are two instructions.  Update the ARMDisassemblerCore.cpp's DisassembleVFPLdStMulFrm()
to reflect the change.

Also add a test case.

llvm-svn: 128103

Fixes rdar://9169640 

llvm-svn: 128100

llvm-svn: 128098

Temporarily reverting these to see if we can get llvm-objdump to link. Hopefully this is not the problem.

llvm-svn: 128097

llvm-svn: 128096