llvm-svn: 86848

llvm-svn: 86847

The TBB and TBH instructions for Thumb2 are really handy for jump tables, but
can only branch forward. To best take advantage of them, we'd like to adjust
the basic blocks around a bit when reasonable. This patch puts basics in place
to do that, with a super-simple algorithm for backwards jump table targets that
creates a new branch after the jump table which branches backwards. Real
heuristics for reordering blocks or other modifications rather than inserting
branches will follow.

llvm-svn: 86791

llvm-svn: 86769

llvm-svn: 86756

llvm-svn: 86754

llvm-svn: 86732

generates a sequence similar to this:

__Z4funci:
LFB2:
        mflr r0
LCFI0:
        stmw r30,-8(r1)
LCFI1:
        stw r0,8(r1)
LCFI2:
        stwu r1,-80(r1)
LCFI3:
        mr r30,r1
LCFI4:

where LCFI3 and LCFI4 are used by the FDE to indicate what the FP, LR, and other
things are. We generated something more like this:

Leh_func_begin1:
        mflr r0
        stw r31, 20(r1)
        stw r0, 8(r1)
Llabel1:
        stwu r1, -80(r1)
Llabel2:
        mr r31, r1

Note that we are missing the "mr" instruction. This patch makes it more like the
GCC output.

llvm-svn: 86729

[r0, #2 * 4]
Now
[r0, #8]

This makes Thumb2 assembly more uniform and frankly the scale doesn't add much.

llvm-svn: 86707

llvm-svn: 86706

 - Force NDEBUG on in any Release build. This drops the compile time to ~100s
   from ~600s, in Release mode.

 - This may just be a temporary workaround, I don't know the true nature of the
   gcc-4.2 compile time performance problem.

llvm-svn: 86695

llvm-svn: 86651

This patch forbids implicit conversion of DenseMap::const_iterator to
DenseMap::iterator which was possible because DenseMapIterator inherited
(publicly) from DenseMapConstIterator. Conversion the other way around is now
allowed as one may expect.

The template DenseMapConstIterator is removed and the template parameter
IsConst which specifies whether the iterator is constant is added to
DenseMapIterator.

Actually IsConst parameter is not necessary since the constness can be
determined from KeyT but this is not relevant to the fix and can be addressed
later.

Patch by Victor Zverovich!

llvm-svn: 86636

llvm-svn: 86634

Allow targets to specify register classes whose member registers should not be renamed to break anti-dependencies. 

llvm-svn: 86628

not necessary.

llvm-svn: 86621

llvm-svn: 86604

llvm-svn: 86602

llvm-svn: 86592

was generated. This caused code like this:

## The asm code for the function
        .section        __TEXT,__const
        .align  2
lJTI11_0:
LJTI11_0:
        .long    LBB11_16
        .long    LBB11_4
        .long    LBB11_5
        .long    LBB11_6
        .long    LBB11_7
        .long    LBB11_8
        .long    LBB11_9
        .long    LBB11_10
        .long    LBB11_11
        .long    LBB11_12
        .long    LBB11_13
        .long    LBB11_14
Leh_func_end11:   ## <---now in the wrong section!

The `Leh_func_end11' would then end up in the wrong section, causing the
resulting EH frame information to be wrong:

__ZL11CheckRightsjPKcbRbRP6NSData.eh:
    .set    Lset500eh,Leh_frame_end11-Leh_frame_begin11
    .long   Lset500eh  ; Length of Frame Information Entry                                                                                                                   
Leh_frame_begin11:
    .long   Leh_frame_begin11-Leh_frame_common
    .long   Leh_func_begin11-.
    .set    Lset501eh,Leh_func_end11-Leh_func_begin11
    .long   Lset501eh                                   ; FDE address range                                                                                                                                   
`Lset501eh' is now something huge instead of the real value.

The X86 back-end generates the jump table after the EH information is
emitted. Do the same here.

llvm-svn: 86588

llvm-svn: 86548

http://llvm.org/bugs/show_bug.cgi?id=5149

llvm-svn: 86543

llvm-svn: 86494

llvm-svn: 86471

llvm-svn: 86470

llvm-svn: 86469

llvm-svn: 86468

llvm-svn: 86466

code miscompilation

llvm-svn: 86463

this gives llvm-gcc generated modules the right data.

llvm-svn: 86435

Use aligned load/store instructions for spilling Q registers when we know the stack slot is 128 bit aligned

llvm-svn: 86425

llvm-svn: 86423

1. rename the movhp patfrag to movlhps, since thats what it actually matches
2. eliminate the bogus movhps load and store patterns, they were incorrect.  The load transforms are already handled (correctly) by shufps/unpack.
3. revert a recent test change to its correct form.

llvm-svn: 86415

llvm-svn: 86408

llvm-svn: 86404

llvm-svn: 86403

llvm-svn: 86400

Please verify.

llvm-svn: 86397

llvm-svn: 86386

llvm-svn: 86385