we don't need -disable-mmx anymore.

llvm-svn: 122189

llvm-svn: 122187

generate them.  

Now we compile:

define zeroext i8 @X(i8 signext %a, i8 signext %b) nounwind ssp {
entry:
  %0 = tail call %0 @llvm.sadd.with.overflow.i8(i8 %a, i8 %b)
  %cmp = extractvalue %0 %0, 1
  br i1 %cmp, label %if.then, label %if.end

into:

_X:                                     ## @X
## BB#0:                                ## %entry
	subl	$12, %esp
	movb	16(%esp), %al
	addb	20(%esp), %al
	jo	LBB0_2

Before we were generating:

_X:                                     ## @X
## BB#0:                                ## %entry
	pushl	%ebp
	movl	%esp, %ebp
	subl	$8, %esp
	movb	12(%ebp), %al
	testb	%al, %al
	setge	%cl
	movb	8(%ebp), %dl
	testb	%dl, %dl
	setge	%ah
	cmpb	%cl, %ah
	sete	%cl
	addb	%al, %dl
	testb	%dl, %dl
	setge	%al
	cmpb	%al, %ah
	setne	%al
	andb	%cl, %al
	testb	%al, %al
	jne	LBB0_2

llvm-svn: 122186

This resolves a README entry and technically resolves PR4916,
but we still get poor code for the testcase in that PR because
GVN isn't CSE'ing uadd with add, filed as PR8817.

Previously we got:

_test7:                                 ## @test7
	addq	%rsi, %rdi
	cmpq	%rdi, %rsi
	movl	$42, %eax
	cmovaq	%rsi, %rax
	ret

Now we get:

_test7:                                 ## @test7
	addq	%rsi, %rdi
	movl	$42, %eax
	cmovbq	%rsi, %rax
	ret

llvm-svn: 122182

It turns out that ppc backend has really weird interdependencies
over different hooks and all stuff is fragile wrt small changes.
This should fix PR8749

llvm-svn: 122155

llvm-svn: 122147

llvm-svn: 122134

ARM::tMOVgpr2gpr. But this check didn't change. As a result, we were getting
misaligned references to the jump table from an ADR instruction.

There is a test case, but unfortunately it's sensitive to random code changes.

<rdar://problem/8782223>

llvm-svn: 122131

llvm-svn: 122129

llvm-svn: 122121

llvm-svn: 122119

The result vector elements are always integers.  Radar 8782191.

llvm-svn: 122112

llvm-svn: 122111

may be called. If the entry block is empty, the insertion point iterator will be
the "end()" value. Calling ->getParent() on it (among others) causes problems.

Modify materializeFrameBaseRegister to take the machine basic block and insert
the frame base register at the beginning of that block. (It's very similar to
what the code does all ready. The only difference is that it will always insert
at the beginning of the entry block instead of after a previous materialization
of the frame base register. I doubt that that matters here.)

<rdar://problem/8782198>

llvm-svn: 122104

The standard error handling in AsmPrinter::EmitInlineAsm handles this much
better, so just use it.

llvm-svn: 122100

Remove unnecessary pandn patterns, 'vnot' patfrag looks through bitcasts

llvm-svn: 122098

a partial value. rdar://8782954

llvm-svn: 122078

llvm-svn: 122076

llvm-svn: 122075

llvm-svn: 122074

llvm-svn: 122067

llvm-svn: 122064

Patch (slightly modified) by Visa Putkinen.

llvm-svn: 122052

llvm-svn: 122044

IsSymbolRefDifferenceFullyResolved, it turns out this does change behavior on
enough cases for x86-32 that I would rather wait a bit on it.
 - In practice, we will want to change this eventually because it only means we
   generate less relocations (it also eliminates the need for the horrible
   '.set' hack that Darwin requires in some places).

llvm-svn: 122042

superceded and was effectively dead.

llvm-svn: 122024

llvm-svn: 122017

llvm-svn: 122005

are correctly marked as used. This removes a hack where the call instructions
marked all possible argument registers as used in the tablegen description.

llvm-svn: 121994

llvm-svn: 121990

interface.

llvm-svn: 121981

llvm-svn: 121973

llvm-svn: 121972

llvm-svn: 121971

the MCCodeEmitter, which seems like a better organization.
 - Also, cleaned up some magic constants while in the area.

llvm-svn: 121953

 - Treaty talks on the non-proliferation of MC objects broke down.

llvm-svn: 121949

(see PR4579).

llvm-svn: 121939

it. I.e., it was always an immediate value.

llvm-svn: 121932

respectively.

It may be a bug that these opcodes are getting this far into machine code
generation.

llvm-svn: 121931

llvm-svn: 121929