something that just glues two nodes together, even if it is
sometimes used for flags.

llvm-svn: 122310

to be the one we want to use. bugpoint reduced testcase is a little large,
I'll see if I can simplify it down more.

Fixes part of rdar://8782207

llvm-svn: 122307

tPseudoInst class, its size was changed from "special" to "2 bytes". This is
incorrect because the jump table will no longer be taken into account when
calculating branch offsets.
<rdar://problem/8782216>

llvm-svn: 122303

llvm-svn: 122302

Implement feedback from Bruno on making pblendvb an x86-specific ISD node in addition to being an intrinsic, and convert
lowering to use it.  Hopefully the pattern fragment is doing the right thing with XMM0, looks correct in testing.

llvm-svn: 122277

llvm-svn: 122269

llvm-svn: 122261

llvm-svn: 122247

llvm-svn: 122246

the same as setcc.  Optimize ADDC(0,0,FLAGS) -> SET_CARRY(FLAGS).  This is
a step towards finishing off PR5443.  In the testcase in that bug we now  get:

	movq	%rdi, %rax
	addq	%rsi, %rax
	sbbq	%rcx, %rcx
	testb	$1, %cl
	setne	%dl
	ret

instead of:

	movq	%rdi, %rax
	addq	%rsi, %rax
	movl	$0, %ecx
	adcq	$0, %rcx
	testq	%rcx, %rcx
	setne	%dl
	ret

llvm-svn: 122219

doesn't, match it back to setb.

On a 64-bit version of the testcase before we'd get:

	movq	%rdi, %rax
	addq	%rsi, %rax
	sbbb	%dl, %dl
	andb	$1, %dl
	ret

now we get:

	movq	%rdi, %rax
	addq	%rsi, %rax
	setb	%dl
	ret

llvm-svn: 122217

llvm-svn: 122214

their carry depenedencies with MVT::Flag operands) and use clean and beautiful
EFLAGS dependences instead.

We do this by changing the modelling of SBB/ADC to have EFLAGS input and outputs
(which is what requires the previous scheduler change) and change X86 ISelLowering
to custom lower ADDC and friends down to X86ISD::ADD/ADC/SUB/SBB nodes.

With the previous series of changes, this causes no changes in the testsuite, woo.

llvm-svn: 122213

has run, e.g., prevent creating an i64 node from a v2i64 when i64 is not a legal type.

llvm-svn: 122206

consistently by moving it out of lowering into dag combine.

Add some missing patterns for matching away extended versions of setcc_c.

llvm-svn: 122201

going through the CSE maps to get it.

llvm-svn: 122196

llvm-svn: 122193

headers provide symbols outside namespace std and the LLVM coding standards
state that we should prefix all of them.

llvm-svn: 122192

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