llvm-svn: 72712

llvm-svn: 72709

ADDC/ADDE use MVT::i1 (later, whatever it gets legalized to)
instead of MVT::Flag.  Remove CARRY_FALSE in favor of 0; adjust
all target-independent code to use this format.

Most targets will still produce a Flag-setting target-dependent
version when selection is done.  X86 is converted to use i32
instead, which means TableGen needs to produce different code
in xxxGenDAGISel.inc.  This keys off the new supportsHasI1 bit
in xxxInstrInfo, currently set only for X86; in principle this
is temporary and should go away when all other targets have
been converted.  All relevant X86 instruction patterns are
modified to represent setting and using EFLAGS explicitly.  The
same can be done on other targets.

The immediate behavior change is that an ADC/ADD pair are no
longer tightly coupled in the X86 scheduler; they can be
separated by instructions that don't clobber the flags (MOV).
I will soon add some peephole optimizations based on using
other instructions that set the flags to feed into ADC.

llvm-svn: 72707

llvm-svn: 72706

llvm-svn: 72705

llvm-svn: 72698

llvm-svn: 72697

llvm-svn: 72696

llvm-svn: 72668

JITCodeEmitter and ObjectCodeEmitter. No functional changes yet. Patch by Aaron Gray

llvm-svn: 72631

llvm-svn: 72618

llvm-svn: 72604

llvm-svn: 72593

llvm-svn: 72558

decoding. Essentially, they both map to the same column in the "opcode
extensions for one- and two-byte opcodes" table in the x86 manual. The RawFrm
complicates decoding this.

Instead, use opcode 0x01, prefix 0x01, and form MRM1r. Then have the code
emitter special case these, a la [SML]FENCE.

llvm-svn: 72556

llvm-svn: 72535

llvm-svn: 72534

llvm-svn: 72531

llvm-svn: 72529

llvm-svn: 72521

is actually legal.  Part of LegalizeDAG cleanups.

llvm-svn: 72513

list in Attributes.h. It also reorders the CPPBackend list to match so that
it's easier to see that it's complete.

llvm-svn: 72510

the Intel manual (screenshot) says it should be 0b11110110 (f6).  The existing
encoding causes a disassembly conflict with MMX_PAVGBrm, which really should be
0f e0."

Patch by Sean Callanan!

llvm-svn: 72508

Added optimization that narrow load / op / store and the 'op' is a bit twiddling instruction and its second operand is an immediate. If bits that are touched by 'op' can be done with a narrower instruction, reduce the width of the load and store as well. This happens a lot with bitfield manipulation code.
e.g.
orl     $65536, 8(%rax)
=>
orb     $1, 10(%rax)

Since narrowing is not always a win, e.g. i32 -> i16 is a loss on x86, dag combiner consults with the target before performing the optimization.

llvm-svn: 72507

llvm-svn: 72494

llvm-svn: 72488

llvm-svn: 72483

FP_TO_XINT.  Necessary for some cleanups I'm working on.  Updated 
from the previous version (r72431) to fix a bug and make some things a 
bit clearer.

llvm-svn: 72445

llvm-svn: 72436

- added processors k8-sse3, opteron-sse3, athlon64-sse3, amdfam10, and
barcelona with appropriate sse3/4a levels
- added FeatureSSE4A for amdfam10 processors
in X86Subtarget:
- added hasSSE4A
- updated AutoDetectSubtargetFeatures to detect SSE4A
- updated GetCurrentX86CPU to detect family 15 with sse3 as k8-sse3 and
family 10h as amdfam10

New processor names match those used by gcc.

Patch by Paul Redmond!

llvm-svn: 72434

FP_TO_XINT.  Necessary for some cleanups I'm working on. 

llvm-svn: 72431

even on Core2, not just AMD processors which was a surprise to me.

llvm-svn: 72396

llvm-svn: 72395

llvm-svn: 72387

nodes it generates.

llvm-svn: 72356

moment.

llvm-svn: 72350

llvm-svn: 72337

llvm-svn: 72336

llvm-svn: 72335

systems instead of attempting to promote them to a 64-bit SINT_TO_FP or 
FP_TO_SINT.  This is in preparation for removing the type legalization 
code from LegalizeDAG: once type legalization is gone from LegalizeDAG, 
it won't be able to handle the i64 operand/result correctly.

This isn't quite ideal, but I don't think any other operation for any 
target ends up in this situation, so treating this case specially seems 
reasonable.

llvm-svn: 72324