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

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

llvm-svn: 186907

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

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

Suppress argumentless aliases for some x86 FP operations from being used by 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

Recommit r186813: More Intel syntax alias fixes. With the addition of 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

instructions. With this patch:

1. ldr.n is recognized as mnemonic for the short encoding
2. ldr.w is recognized as menmonic for the long encoding
3. ldr will map to either short or long encodings depending on the size of the offset

llvm-svn: 186831

.ftz to instructions if the nvptx-f32ftz attribute is set to "true"

llvm-svn: 186820

This reverts commit r186813, which broke the bots.

llvm-svn: 186818

llvm-svn: 186815

llvm-svn: 186814

llvm-svn: 186813

llvm-svn: 186812

llvm-svn: 186811

After Ulrich's r180677 (thanks!) TableGen is intelligent enough to
handle tied constraints involving complex operands properly, so
virtually all of the ARM custom converters are now unnecessary.

llvm-svn: 186810

llvm-svn: 186809

deallocation functions.

llvm-svn: 186798

llvm-svn: 186787

indirect branches correctly. Under some circumstances, this led to the deletion
of basic blocks that were the destination of indirect branches. In that case it
left indirect branches to nowhere in the code.

This patch replaces, and is more general than either of the previous fixes for
indirect-branch-analysis issues, r181161 and r186461.

For other branches (not indirect) this refactor should have *almost* identical
behavior to the previous version. There are some corner cases where this
refactor is able to analyze blocks that the previous version could not (e.g.
this necessitated the update to thumb2-ifcvt2.ll). 

<rdar://problem/14464830>

llvm-svn: 186735

llvm-svn: 186725