Spacing fixes and using 'unsigned' instead of 'int' to index to select shuffle elements for consistency with other shuffle code in X86 backend.

llvm-svn: 153154

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

vextractf128 with 128-bit mem dest.

Combines

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

to

    vextractf128 $0, %ymm0, (%rdi)

rdar://11082570

llvm-svn: 153139

llvm-svn: 153135

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

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

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

llvm-svn: 153063

rdar://11059157

llvm-svn: 153055

rdar://11057160

llvm-svn: 153053

Patch by Weiming Zhao!
This fixes PR12212

llvm-svn: 153049

X86InstrCompiler.td.
 
It also adds –mcpu-generic to the legalize-shift-64.ll test so the test
will pass if run on an Intel Atom CPU, which would otherwise
produce an instruction schedule which differs from that which the test expects.

llvm-svn: 153033

llvm-svn: 153031

llvm-svn: 153027

Reorder includes in Target backends to following coding standards. Remove some superfluous forward declarations.

llvm-svn: 152997

llvm-svn: 152981

llvm-svn: 152980

Pass TargetOptions to HexagonTargetMachine constructor by reference to match other targets and the base class.

llvm-svn: 152979

llvm-svn: 152978

fast-isel before emitting code. If the program bails after code was emitted,
then it could lead to the stack being adjusted more than once (two
CALLSEQ_BEGINs emitted) but being adjuste back only once after the call. This
leads to general badness and gnashing of teeth.
<rdar://problem/11050630>

llvm-svn: 152959

rdar://11065671

llvm-svn: 152954

llvm-svn: 152946

It's not a good style idea, as the registers will be laid down in memory in
numerical order, not the order they're in the list, but it's legal. vldm/vstm
are stricter.

rdar://11064740

llvm-svn: 152943

rdar://11058464

llvm-svn: 152883

rdar://11058464

llvm-svn: 152881

llvm-svn: 152870

and still allow immediate encoding, just not with cmn.
rdar://11038907

llvm-svn: 152869

rdar://11038907

llvm-svn: 152847

rdar://11056591

llvm-svn: 152846

rdar://11056647

llvm-svn: 152834