at the start of basic blocks to their common predecessor. It's actually quite
common (e.g. about 50 times in JM/lencod) and has shown to be a nice code size
benefit. e.g.

        pushq   %rax
        testl   %edi, %edi
        jne     LBB0_2
## BB#1:
        xorb    %al, %al
        popq    %rdx
        ret
LBB0_2:
        xorb    %al, %al
        callq   _foo
        popq    %rdx
        ret

=>

        pushq   %rax
        xorb    %al, %al
        testl   %edi, %edi
        je      LBB0_2
## BB#1:
        callq   _foo
LBB0_2:
        popq    %rdx
        ret

rdar://9145558

llvm-svn: 131172

Next up: xor and and.

Part of rdar://8470697

llvm-svn: 131171

llvm-svn: 131169

llvm-svn: 131164

llvm-svn: 131162

llvm-svn: 131161

llvm-svn: 131160

headers.

llvm-svn: 131159

llvm-svn: 131157

llvm-svn: 131156

Add support for plugins add passes to the default set of passes.  The standard set of passes used by front ends can now be modified by LLVM plugins, without needing to modify any front ends.

Still to do:

- Allow replacing / removing passes (infrastructure there, just needs an infrastructure exposed)
- Defining sets of passes to be added or removed as a group
- Extending the support to allow user-defined groups of optimisations
- Allow plugins to be specified for loading automatically (e.g. from plugins.conf or some similar mechanism)

Reviewed by Nick Lewycky.

llvm-svn: 131155

test case; I've only seen this on a release branch, and I can't get it
to reproduce on trunk.  rdar://problem/7662569

llvm-svn: 131152

llvm-svn: 131151

llvm-svn: 131149

DwarfRequiresRelocationForSectionOffset as this is not specific to StmtList.

llvm-svn: 131148

llvm-svn: 131146

this clang will use .debug_frame in, for example,
clang -g -c -m32 test.c
This matches gcc's behaviour. It looks like .debug_frame is a bit bigger
than .eh_frame, but has the big advantage of not being allocated.

llvm-svn: 131140

cut and paste.

llvm-svn: 131139

DWARF stuff also gets fixed up by ELFARMAsmBackend::ApplyFixup(),
but the offset is not guaranteed to be mod 4 == 0 as in text/data. 

llvm-svn: 131137

Ambiguous sub-register index compositions are OK as long as the backend writer
knows what he is doing.

llvm-svn: 131134

The previous invalidation missed the alias interference caches.

Also add a stats counter for the number of repaired ranges.

llvm-svn: 131133

llvm-svn: 131129

Patch by Dan Bailey

llvm-svn: 131128

one of the sections is created.

llvm-svn: 131124

Patch by Wei-Ren Chen

llvm-svn: 131123

llvm-svn: 131121

llvm-svn: 131120

llvm-svn: 131119

llvm-svn: 131118

llvm-svn: 131117

llvm-svn: 131112

llvm-svn: 131106

llvm-svn: 131094

Patch by Evan Cheng.

llvm-svn: 131093

llvm-svn: 131088

Patch by Liu <proljc@gmail.com>!

llvm-svn: 131086

llvm-svn: 131085

llvm-svn: 131082

llvm-svn: 131078

It can happen that a live debug variable is the last use of a sub-register, and
the register allocator will pick a larger register class for the virtual
register.  If the allocated register doesn't support the sub-register index,
just use %noreg for the debug variables instead of asserting.

In PR9872, a debug variable ends up in the sub_8bit_hi part of a GR32_ABCD
register. The register is split and one part is inflated to GR32 and assigned
%ESI because there are no more normal uses of sub_8bit_hi.

Since %ESI doesn't have that sub-register, substPhysReg asserted. Now it will
simply insert a %noreg instead, and the debug variable will be marked
unavailable in that range.

We don't currently have a way of saying: !"value" is in bits 8-15 of %ESI, I
don't know if DWARF even supports that.

llvm-svn: 131073