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: 72485

llvm-svn: 72483

llvm-svn: 72480

used by CMake with --ldflags.

llvm-svn: 72470

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: 72443

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

pthreads, otherwise ar complains of unresolved references to pthread_mutex_*.
LTO doesn't actually use pthreads, but ManagedStatic does.

Fix this by linking in LIBS (that contains pthreads) for LTO and gold.
For now this links in more libs than needed (libffi for example), we can figure
out later how to link in those libs per-tool later.

llvm-svn: 72430

entries as there are basic blocks in the function.  LiveVariables::getVarInfo
creates a VarInfo struct for every register in the function, leading to
quadratic space use.  This patch changes the BitVector to a SparseBitVector,
which doesn't help the worst-case memory use but does reduce the actual use in
very long functions with short-lived variables.

llvm-svn: 72426

that of the LHS. It doesn't matter for correctness, but the LHS
is more likely than the RHS to be a pointer type in exotic cases,
and it's more tidy to have it return the integer type.

llvm-svn: 72424

llvm-svn: 72423

division operation, don't attempt to use the operation's value as
the base of a getelementptr. This fixes PR4271.

llvm-svn: 72422

llvm-svn: 72414

llvm-svn: 72411

low-level alias() method, allowing it to reason more aggressively
about pointers into constant memory.  PR4189

llvm-svn: 72403

or use labels as members of structures for example. Also included a couple of
whitespace fixes.

llvm-svn: 72402

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

llvm-svn: 72396

llvm-svn: 72395

llvm-svn: 72387

can't just eliminate all global initializers.

llvm-svn: 72378