This is not supposed to happen, but I have seen the x86 rematter getting
confused when rematerializing partial redefs.

llvm-svn: 127857

and early clobbers.

Assert when trying to find an undefined value.

llvm-svn: 127856

Add new CrashRecoveryContextCleanup subclass: CrashRecoveryContextDeleteCleanup.  This deletes the object, not just calls its destructor.

llvm-svn: 127855

llvm-svn: 127853

comparisons on x86.  Essentially, the way this works is that SUB+SBB sets
the relevant flags the same way a double-width CMP would.

This is a substantial improvement over the generic lowering in LLVM. The output
is also shorter than the gcc-generated output; I haven't done any detailed
benchmarking, though.

llvm-svn: 127852

Augment CrashRecoveryContext to have registered "cleanup" objects that can be used to release resources during a crash.

llvm-svn: 127849

llvm-svn: 127845

Remove the offending logic and update the test cases.

llvm-svn: 127843

llvm-svn: 127842

llvm-svn: 127840

SCEV may generate expressions composed of multiple pointers, which can
lead to invalid GEP expansion. Until we can teach SCEV to follow strict
pointer rules, make sure no bad GEPs creep into IR.
Fixes rdar://problem/9038671.

llvm-svn: 127839

llvm-svn: 127837

instead of copying.

llvm-svn: 127835

This is done by lowering dbg.declare intrinsic into dbg.value intrinsic.
Radar 9143931.

llvm-svn: 127834

o A8.6.195 STR (register) -- Encoding T1
o A8.6.193 STR (immediate, Thumb) -- Encoding T1

It has been changed so that now they use different addressing modes
and thus different MC representation (Operand Infos).  Modify the
disassembler to reflect the change, and add relevant tests.

llvm-svn: 127833

llvm-svn: 127832

BuildUDIV: If the divisor is even we can simplify the fixup of the multiplied value by introducing an early shift.

This allows us to compile "unsigned foo(unsigned x) { return x/28; }" into
	shrl	$2, %edi
	imulq	$613566757, %rdi, %rax
	shrq	$32, %rax
	ret

instead of
	movl    %edi, %eax
	imulq   $613566757, %rax, %rcx
	shrq    $32, %rcx
	subl    %ecx, %eax
	shrl    %eax
	addl    %ecx, %eax
	shrl    $4, %eax

on x86_64

llvm-svn: 127829

Add an argument to APInt's magic udiv calculation to specify the number of bits that are known zero in the divided number.

This will come in handy soon.

llvm-svn: 127828

I have convinced myself that it can only happen when a phi value dies. When it
happens, allocate new virtual registers for the components.

llvm-svn: 127827

llvm-svn: 127824

llvm-svn: 127821

llvm-svn: 127814

llvm-svn: 127813

been removed.

llvm-svn: 127812

llvm-svn: 127809

llvm-svn: 127808

llvm-svn: 127807

llvm-svn: 127801

test/CodeGen/X86/h-registers-1.ll: Add explicit -mtriple=x86_64-linux. It does not need to be checked on x86_64-win32 (aka Win64).

llvm-svn: 127800

llvm-svn: 127788

llvm-svn: 127786

of an file.

llvm-svn: 127781

While here, add VK_ARM_TPOFF and VK_ARM_GOTTPOFF, too.

llvm-svn: 127780

llvm-svn: 127779

llvm-svn: 127775

The register allocator needs to adjust its live interval unions when that happens.

llvm-svn: 127774

llvm-svn: 127773

The live range of a virtual register may change which invalidates the cached
interference information.

llvm-svn: 127772

llvm-svn: 127771

rather than an int. Thankfully, this only causes LLVM to miss optimizations, not
generate incorrect code.

This just fixes the zext at the return. We still insert an i32 ZextAssert when
reading a function's arguments, but it is followed by a truncate and another i8
ZextAssert so it is not optimized.

llvm-svn: 127766