operands.

llvm-svn: 187238

llvm-svn: 187234

to have register FCC0 (the first floating point condition code register) in
their Uses/Defs list.

No intended functionality change.

llvm-svn: 187233

needed. The generic method printOperand will do.

No functionality change.

llvm-svn: 187231

instructions "beqz", "bnez" and "move", when possible.

beq $2, $zero, $L1 => beqz $2, $L1
bne $2, $zero, $L1 => bnez $2, $L1
or  $2, $3, $zero  => move $2, $3

llvm-svn: 187229

CustomLowerNode was not being called during SplitVectorOperand,
meaning custom legalization could not be used by targets.

This also adds a test case for NVPTX that depends on this custom
legalization.

Differential Revision: http://llvm-reviews.chandlerc.com/D1195

Attempt to fix the buildbots by making the X86 test I just added platform independent

llvm-svn: 187202

This reverts commit 187198. It broke the bots.

The soft float test probably needs a -triple because of name differences.
On the hard float test I am getting a "roundss $1, %xmm0, %xmm0", instead of
"vroundss $1, %xmm0, %xmm0, %xmm0".

llvm-svn: 187201

CustomLowerNode was not being called during SplitVectorOperand,
meaning custom legalization could not be used by targets.

This also adds a test case for NVPTX that depends on this custom
legalization.

Differential Revision: http://llvm-reviews.chandlerc.com/D1195

llvm-svn: 187198

llvm-svn: 187195

llvm-svn: 187193

llvm-svn: 187187

llvm-svn: 187182

This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code.  Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing.  Code generation will otherwise be the same as
powerpc64 (big-endian), for now.

The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.

The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists.  There is nothing of any import
worth testing until such time as little-endian code generation is
implemented.  In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.

llvm-svn: 187179

structure not just a pointer. This implements that and thus fixes va_copy
on PPC32. Fixes #15286. Both bug and patch by Florian Zeitz!

llvm-svn: 187158

Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html

llvm-svn: 187145

The last patch corrected some issues, but constant-pool entries had actual
codegen bugs in the large memory model (which MCJIT uses).

llvm-svn: 187126

Before the patch we took advantage of the fact that the compare and
branch are glued together in the selection DAG and fused them together
(where possible) while emitting them.  This seemed to work well in practice.
However, fusing the compare so early makes it harder to remove redundant
compares in cases where CC already has a suitable value.  This patch
therefore uses the peephole analyzeCompare/optimizeCompareInstr pair of
functions instead.

No behavioral change intended, but it paves the way for a later patch.

llvm-svn: 187116

llvm-svn: 187113

As with the stores, these instructions can trap when the condition is false,
so they are only used for things like (cond ? x : *ptr).

llvm-svn: 187112

These instructions are allowed to trap even if the condition is false,
so for now they are only used for "*ptr = (cond ? x : *ptr)"-style
constructs.

llvm-svn: 187111

There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.

llvm-svn: 187093

when there wasn't a match. This behavior is consistent with other register
parsing methods.

llvm-svn: 187063

Testing commit access credentials.

llvm-svn: 187032

I'm starting to commit KNL backend. I'll push patches one-by-one. This patch includes support for the extended register set XMM16-31, YMM16-31, ZMM0-31.
The full ISA you can see here: http://software.intel.com/en-us/intel-isa-extensions

llvm-svn: 187030

llvm-svn: 187027

This removes the need to store the asm variant in each row of the single table that existed before. Shaves ~16K off the size of X86AsmParser.o.

llvm-svn: 187026

llvm-svn: 187021

Fix aliases for shrd/shld to handle Intel syntax properly. Also suppress them from being used by the asm printer.

llvm-svn: 187020

This commit also implements these functions for R600 and removes a test
case that was relying on the buggy behavior.

llvm-svn: 187007

These are really the same address space in hardware.  The only
difference is that CONSTANT_ADDRESS uses a special cache for faster
access.  When we are unable to use the constant kcache for some reason
(e.g. smaller types or lack of indirect addressing) then the instruction
selector must use GLOBAL_ADDRESS loads instead.

llvm-svn: 187006

When vectors are built from a single value, the ARM lowering issues a
scalar_to_vector node.
This node is then always morphed into a move from the general purpose unit to
the vector unit.
When the value comes from a load, this can be simplified into a vector load to
the right lane.

This patch changes the lowering of insert_vector_elt to expose a vector
friendly pattern in this situation.

This is a step toward fixing <rdar://problem/14170854>.

llvm-svn: 186999

llvm-svn: 186932

llvm-svn: 186924

Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186923

Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186922

Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186921

Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186920

This increases the number of opportunites we have for folding.  With the
previous implementation we were unable to fold into any instructions
other than the first when multiple instructions were selected from a
single SDNode.

Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186919

Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186918

Before:

MOV * T0.W, KC0[131-128].Y

After:

MOV * T0.W, KC0[3].Y

Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186917