| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
in a subsequent patch.
llvm-svn: 187187
|
| |
|
|
|
|
| |
static tables.
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
asm variant.
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
normal movsl instead.
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
|
| |
|
|
|
|
|
|
| |
A side-effect of this is that now the compiler expects kernel arguments
to be 4-byte aligned.
Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186916
|
| |
|
|
|
| |
Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186915
|
| |
|
|
|
| |
Reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 186914
|
| |
|
|
| |
llvm-svn: 186913
|
| |
|
|
| |
llvm-svn: 186910
|
| |
|
|
|
|
| |
normal movsl instead.
llvm-svn: 186907
|
| |
|
|
|
|
|
|
| |
to their 32-bit forms.
This makes them consistent with 'bt' which already had this handling. gas has the same behavior. There have been discussions on the mailing list about determining size based on the immediate, but my goal here was just to remove the inconsistency.
llvm-svn: 186904
|
| |
|
|
|
|
|
|
| |
%reg.
It only didn't use it before because it seems InstAlias handling in the asm printer fails to count tied operands so it tried to find an xor with 2 operands instead of the 3 it wfails to count tied.
llvm-svn: 186900
|
| |
|
|
|
|
| |
the asm writer. Prefer to use the explicit %st(1) form.
llvm-svn: 186897
|
| |
|
|
|
|
|
|
| |
absolute address encoded in the instruction.
rdar://8612627 and rdar://14299221
llvm-svn: 186878
|
| |
|
|
|
|
| |
suppressing some of the aliases from being emitted by the asm printer.
llvm-svn: 186869
|
| |
|
|
|
|
|
|
| |
Enable parsing all 32 floating point control registers $0-31 and stop trying to
parse floating point condition code register $fcc0. Also, return ParseFail if
the operand being parsed is not in the expected format.
llvm-svn: 186861
|
| |
|
|
|
|
|
| |
the InstAlias pattern which maps "move" to OR to resolve ambiguity in
MatchTable.
llvm-svn: 186855
|
| |
|
|
| |
llvm-svn: 186844
|