unpredicated. That is, turn
 subeq  r0, r1, #1
 addne  r0, r1, #1                                                                                                                                                                                                     
into
 sub    r0, r1, #1
 addne  r0, r1, #1

For targets where conditional instructions are always executed, this may be
beneficial. It may remove pseudo anti-dependency in out-of-order execution
CPUs. e.g.
 op    r1, ...
 str   r1, [r10]        ; end-of-life of r1 as div result
 cmp   r0, #65
 movne r1, #44  ; raw dependency on previous r1
 moveq r1, #12

If movne is unpredicated, then
 op    r1, ...
 str   r1, [r10]
 cmp   r0, #65
 mov   r1, #44  ; r1 written unconditionally
 moveq r1, #12

Both mov and moveq are no longer depdendent on the first instruction. This gives
the out-of-order execution engine more freedom to reorder them.

This has passed entire LLVM test suite. But it has not been enabled for any ARM
variant pending more performance evaluation.

rdar://8951196

llvm-svn: 146914

patterns emit a single LUi instruction instead of a pair of LUi and ORi.

llvm-svn: 146900

llvm-svn: 146897

llvm-svn: 146896

rdar://10602276

llvm-svn: 146895

direct-object emitter should emit the appropriate shift instruction depending
on the shift amount.

llvm-svn: 146893

llvm-svn: 146892

llvm-svn: 146889

This change reduces the number of instructions generated.

For example, 
(load (add (sub $n0, $n1), (MipsLo got(s))))

results in the following sequence of instructions:
1. sub $n2, $n0, $n1
2. lw got(s)($n2)

Previously, three instructions were needed.
1. sub $n2, $n0, $n1
2. addiu $n3, $n2, got(s)
3. lw 0($n3)

llvm-svn: 146888

llvm-svn: 146887

llvm-svn: 146885

There's more variation that we need to handle. Error checking will need
to be on operand predicates.

llvm-svn: 146884

llvm-svn: 146882

Add the new TableGen register class synthesizer feature to the release
notes.

llvm-svn: 146875

Now that getMatchingSuperRegClass() returns accurate results, it can be
used to compute constraints imposed by instructions using a sub-register
of a virtual register.

This means we can recompute the register class of any virtual register
by combining the constraints from all its uses.

llvm-svn: 146874

Use information computed while inferring new register classes to emit
accurate, table-driven implementations of getMatchingSuperRegClass().

Delete the old manual, error-prone implementations in the targets.

llvm-svn: 146873

- Remove trailing spaces.

llvm-svn: 146854

llvm-svn: 146852

attribute themselve.

llvm-svn: 146851

Some compilers were complaining about passing StringRef to it.

llvm-svn: 146850

llvm-svn: 146846

internal nightly testers.  Original commit message:

By popular demand, link up types by name if they are isomorphic and one is an
autorenamed version of the other.   This makes the IR easier to read, because
we don't end up with random renamed versions of the types after LTO'ing a large
app.

llvm-svn: 146838

Hope I did this correctly :)

llvm-svn: 146834

llvm-svn: 146833

llvm-svn: 146831

SimplifyCFG now predicts some conditional branches to true or false depending on previous branch on same comparison operands.

For example, 

if (a == b) {
    if (a > b) // this is false
    
Fixes some of the issues on <rdar://problem/10554090>

llvm-svn: 146822

llvm-svn: 146805

This will be used by SimplifyCfg in a later commit.

llvm-svn: 146803

asm parsing and testcase.

llvm-svn: 146801

llvm-svn: 146800

I don't think this affects anything but verbose assembly.

llvm-svn: 146787

"half precision" floating-point with a first-class type.

This patch adds basic IR support (but not codegen support).

llvm-svn: 146786

pointer or a reference type - we actually just want the size of the
pointer then for that.

Fixes rdar://10335756

llvm-svn: 146785

llvm-svn: 146784

llvm-svn: 146783

llvm-svn: 146780

The bad sorting caused a misaligned basic block when building 176.vpr in
ARM mode.

<rdar://problem/10594653>

llvm-svn: 146767

Hexatridecimal was added in r139695.

And fix the unittest that now triggers the assert.

llvm-svn: 146754

This adjustment is already included in the block offsets computed by
BasicBlockInfo, and adjusting again here can cause the pass to loop.

When CreateNewWater splits a basic block, OffsetIsInRange would reject
the new CPE on the next pass because of the too conservative alignment
adjustment. This caused the block to be split again, and so on.

llvm-svn: 146751

Reenable the tests.

llvm-svn: 146750