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

llvm-svn: 86384

llvm-svn: 86383

llvm-svn: 86382

llvm-svn: 86381

llvm-svn: 86380

llvm-svn: 86379

Add assert in asmprinter to catch such cases and xfail the tests.
PR is to be filled.

llvm-svn: 86375

datatypes on a given CPU.  This is intended to allow instcombine and other
transformations to avoid converting big sequences of operations to an
inconvenient width, and will help clean up after SRoA.  See also "Adding 
legal integer sizes to TargetData" on Feb 1, 2009 on llvmdev, and PR3451.

Comments welcome.

llvm-svn: 86370

llvm-svn: 86369

llvm-svn: 86367

llvm-svn: 86366

MachineRelocations, "stub" always refers to a far-call stub or a
load-a-faraway-global stub, so this patch adds "Far" to the term. (Other stubs
are used for lazy compilation and dlsym address replacement.) The variable was
also inconsistent between the positive and negative sense, and the positive
sense ("NeedStub") was more demanding than is accurate (since a nearby-enough
function can be called directly even if the platform often requires a stub).
Since the negative sense causes double-negatives, I switched to
"MayNeedFarStub" globally.

llvm-svn: 86363

of movhps as the constraint.  Changes optimizations so
update testcases as appropriate as well.

llvm-svn: 86360