These changes allow us to compile big endian from the command line for 32 bit
Mips targets. This patch will result in code and data actually being produced
in the correct endianess.

llvm-svn: 153153

llvm-svn: 153150

ImmutAVLTree uses random unsigned values as keys into a DenseMap,
which could possibly happen to be the same value as the Tombstone or
Entry keys in the DenseMap.

Test case is hard to come up with. We randomly get failures on the
internal static analyzer bot, which most likely hits this issue
(hard to be 100% sure without the full stack).

llvm-svn: 153148

relocations (i.e., pieces of data whose addresses
are referred to elsewhere in the binary image) and
update the references when the section containing
the relocations moves.  The way this works is that
there is a map from section IDs to lists of
relocations.

Because the relocations are associated with the
section containing the data being referred to, they
are updated only when the target moves.  However,
many data references are relative and also depend
on the location of the referrer.

To solve this problem, I introduced a new data
structure, Referrer, which simply contains the
section being referred to and the index of the
relocation in that section.  These referrers are
associated with the source containing the
reference that needs to be updated, so now
regardless of which end of the relocation moves,
the relocation will now be updated correctly.

llvm-svn: 153147

llvm-svn: 153140

vextractf128 with 128-bit mem dest.

Combines

	vextractf128 $0, %ymm0, %xmm0
	vmovaps %xmm0, (%rdi)

to

    vextractf128 $0, %ymm0, (%rdi)

rdar://11082570

llvm-svn: 153139

rdar://11027851

llvm-svn: 153137

llvm-svn: 153136

llvm-svn: 153135

Do not call SplitBlockPredecessors on a loop preheader when one of the
predecessors is an indirectbr. Otherwise, you will hit this assert:
!isa<IndirectBrInst>(Preds[i]->getTerminator()) && "Cannot split an edge from an IndirectBrInst"

llvm-svn: 153134

llvm-svn: 153133

llvm-svn: 153132

instead of skipping the current loop.

My prior fix was incomplete because of an overzealous compile-time optimization:
Better fix for: <rdar://problem/11049788> Segmentation fault: 11 in LoopStrengthReduce

llvm-svn: 153131

llvm-svn: 153125

llvm-svn: 153116

precedence over the VINSERTF128 avx1 patterns.

llvm-svn: 153114

ARMBaseRegisterInfo::canRealignStack was checking for variable-sized objects
but not for stack adjustments around calls.  Use hasReservedCallFrame() to
check for both.  The hasBasePointer function was already correctly checking
both conditions, so the effect of this was that a base pointer would be used
without checking whether the base pointer register could be reserved. I don't
have a small testcase for this.

<rdar://problem/11075906>

llvm-svn: 153110

ARMFrameLowering::hasReservedCallFrame is already checking for variable
sized objects, so there's no point in checking it twice.

llvm-svn: 153109

llvm-svn: 153105

whitespace from test case.  No functional change intended.

llvm-svn: 153103

llvm-svn: 153099

Needed when building -mdynamic-no-pic code.

rdar://10459256

llvm-svn: 153097

llvm-svn: 153095

This results in things such as

	vmovups	16(%rdi), %xmm0
	vinsertf128	$1, %xmm0, %ymm0, %ymm0

to be combined to

    vinsertf128	$1, 16(%rdi), %ymm0, %ymm0

rdar://11076953

llvm-svn: 153092

The ARM instructions that have an unpredictable behavior when the pc register operand is given now fail with soft fail. Modified the regression tests to reflect this.

llvm-svn: 153089

llvm-svn: 153086

llvm-svn: 153083

i128). In that case, we may not be able to print out the MCExpr as an
expression. For instance, we could have an MCExpr like this:

    0xBEEF0000BEEF0000 | (0xBEEF0000BEEF0000 << 64)

The MCExpr printer handles sizes up to 64-bits, but this expression would
require 128-bits. In this situation, try to evaluate the constant expression and
emit that as the value into 64-bit chunks.
<rdar://problem/11070338>

llvm-svn: 153081

Remove code that prevented lowering shuffles if they are used by load and themselves used by a extract_vector_elt. This was done to allow the DAG combiner to collapse to a single element load. Unfortunately, sometimes the extract_vector_elt would disappear before DAG combine could do the transformation leaving a vector_shuffle that isel couldn't handle. New code lets the shuffle be converted to a target specific node, but then adds a combine routine that can convert target specific nodes back to vector_shuffles if the folding criteria are met.

llvm-svn: 153080

Factor out target shuffle mask decoding from getShuffleScalarElt and use a SmallVector of int instead of unsigned for shuffle mask in decode functions. Preparation for another change.

llvm-svn: 153079

When combining (vextract shuffle (load ), <1,u,u,u>), 0) -> (load ), add users of the final load to the worklist too. Needed by changes I'm preparing to make to X86 backend.

llvm-svn: 153078

a variable. The previous code would break the debug info changing
code invariant. This will regress debug info for arguments where
we elide the alloca created.

Fixes rdar://11066468

llvm-svn: 153074

llvm-svn: 153073

llvm-svn: 153072

llvm-svn: 153071

1) opt is not usually in the same path as the target program. Even for
the bugpoint as a standalone app, it should be more portable to search
in PATH, isn't it?
2) bugpoint driver accounts opt plugins, but does not list them in the
final output command.

Patch by Dmitry Mikushin!

llvm-svn: 153066

llvm-svn: 153065

llvm-svn: 153064

llvm-svn: 153063

rdar://11059157

llvm-svn: 153055