rdar://problem/8614450

llvm-svn: 131746

llvm-svn: 131654

pseudos.  rdar://problem/8614450

llvm-svn: 131641

Finishes off rdar://8470697

llvm-svn: 131458

Next up: xor and and.

Part of rdar://8470697

llvm-svn: 131171

cut and paste.

llvm-svn: 131139

"b + ((a < b) ? 1 : 0)" compiles into
	cmpl	%esi, %edi
	adcl	$0, %esi
instead of
	cmpl	%esi, %edi
	sbbl	%eax, %eax
	andl	$1, %eax
	addl	%esi, %eax

This saves a register, a false dependency on %eax
(Intel's CPUs still don't ignore it) and it's shorter.

llvm-svn: 131070

these patterns.

llvm-svn: 125759

llvm-svn: 124272

llvm-svn: 124270

the flags.

llvm-svn: 123712

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

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

llvm-svn: 121908

llvm-svn: 121328

llvm-svn: 120263

llvm-svn: 120225

various X86 and ARM instructions that are bitten by this as isCodeGenOnly,
as they are.

llvm-svn: 117884

and make it a hard error for instructions to not have an asm string.
These instructions should be marked isCodeGenOnly.

llvm-svn: 117861

llvm-svn: 116984

llvm-svn: 116972

immediates instead of 8 bits ones.

llvm-svn: 116410

8 bit constants can be used.

llvm-svn: 116403

llvm-svn: 116319

reapply: reimplement the second half of the or/add optimization.  We should now

with no changes.  Turns out that one missing "Defs = [EFLAGS]" can upset things
a bit.

llvm-svn: 116040

"Reimplement (part of) the or -> add optimization.  Matching 'or' into 'add'"

With a critical fix: the add pseudos clobber EFLAGS.

llvm-svn: 116039

'add'", which seems to have broken just about everything.

llvm-svn: 116033

which depends on r116007, which I am about to revert.

llvm-svn: 116031

only end up emitting LEA instead of OR.  If we aren't able to promote
something into an LEA, we should never be emitting it as an ADD.

Add some testcases that we emit "or" in cases where we used to produce
an "add".

llvm-svn: 116026

is general goodness because it allows ORs to be converted to LEA to avoid
inserting copies.  However, this is bad because it makes the generated .s
file less obvious and gives valgrind heartburn (tons of false positives in
bitfield code).

While the general fix should be in valgrind, we can at least try to avoid
emitting ADD instructions that *don't* get promoted to LEA.  This is more
work because it requires introducing pseudo instructions to represents
"add that knows the bits are disjoint", but hey, people really love valgrind.

This fixes this testcase:
https://bugs.kde.org/show_bug.cgi?id=242137#c20

the add r/i cases are coming next.

llvm-svn: 116007

convert all the rest of the cmovs to the multiclass,
with good results:

 X86InstrCMovSetCC.td |  598 +--------------------------------------------------
 X86InstrCompiler.td  |   61 +++++
 2 files changed, 77 insertions(+), 582 deletions(-)

llvm-svn: 115707

(e.g. CMOVBE16rr instead of CMOVBErr16).

llvm-svn: 115705

simplify the X86 CMOVmr's.

llvm-svn: 115702

and verbosity

llvm-svn: 115701

21 insertions(+), 53 deletions(-)

Moar change coming before I switch the rest.

llvm-svn: 115697

llvm-svn: 115686

bswap32 doesn't read eflags.

llvm-svn: 115604

pseudo instructions.

Move POPCNT to InstrSSE since they are SSE4 instructions.

llvm-svn: 115603

with the 32-bit stuff.

llvm-svn: 115602

llvm-svn: 115601