llvm-svn: 72558

llvm-svn: 72557

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

This patch removes some special cases for opcodes and does a bit of 
cleanup.

llvm-svn: 72536

llvm-svn: 72535

llvm-svn: 72534

llvm-svn: 72533

llvm-svn: 72531

failure during llvm-gcc bootstrap:

Assertion failed: (!Tmp2.getNode() && "Can't legalize BR_CC with legal condition!"), function ExpandNode, file /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/src/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 2923.
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/gcc/libgcc2.c:1727: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.

llvm-svn: 72530

llvm-svn: 72529

llvm-svn: 72521

llvm-svn: 72516

This is basically the end of this series of patches for LegalizeDAG; the 
remaining special cases can't be removed without more infrastructure 
work.  There's a FIXME for each relevant opcode near the beginning of
SelectionDAGLegalize::LegalizeOp.

llvm-svn: 72514

is actually legal.  Part of LegalizeDAG cleanups.

llvm-svn: 72513

empty SmallVector.

llvm-svn: 72512

some special cases are necessary.

llvm-svn: 72511

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

llvm-svn: 72509

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

rewrite the comparison if there is any implicit extension or truncation
on the induction variable. I'm planning for IVUsers to eventually take
over some of the work of this code, and for it to be generalized.

llvm-svn: 72496

llvm-svn: 72494

a smaller type, promoted its offset back up to the type of the new
comparison. This fixes PR4222.

llvm-svn: 72493

llvm-svn: 72488

llvm-svn: 72483

llvm-svn: 72480

BUILD_VECTOR.

llvm-svn: 72469

llvm-svn: 72468

llvm-svn: 72467

llvm-svn: 72465

llvm-svn: 72464

llvm-svn: 72456

llvm-svn: 72455

llvm-svn: 72454

llvm-svn: 72453

possible. For example, it now emits

  %p.2.ip.1 = getelementptr [3 x [3 x double]]* %p, i64 2, i64 %tmp, i64 1

instead of the equivalent but less obvious

  %p.2.ip.1 = getelementptr [3 x [3 x double]]* %p, i64 0, i64 %tmp, i64 19

llvm-svn: 72452

beyond their associated static array type.

I believe that this fixes a legitimate bug, because BasicAliasAnalysis
already has code to check for this condition that works for non-constant
indices, however it was missing the case of constant indices. With this
change, it checks for both.

This fixes PR4267, and miscompiles of SPEC 188.ammp and 464.h264.href.

llvm-svn: 72451

handling for every single opcode.

llvm-svn: 72447

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