respective ABI plugins as they were plug-ins that supplied ABI specfic info.

Also hookep up the UnwindAssemblyInstEmulation so that it can generate the
unwind plans for ARM.

Changed the way ABI plug-ins are handed out when you get an instance from
the plug-in manager. They used to return pointers that would be mananged
individually by each client that requested them, but now they are handed out
as shared pointers since there is no state in the ABI objects, they can be
shared.

llvm-svn: 131193

about to be spilled.

This can only happen when two extra snippet registers are included in the spill,
and there is a copy between them. Hoisting the spill creates problems because
the hoist will mark the copy for later dead code elimination, and spilling the
second register will turn the copy into a spill.

<rdar://problem/9420853>

llvm-svn: 131192

llvm-svn: 131191

llvm-svn: 131190

llvm-svn: 131189

Concludes // radar://8823265.

llvm-svn: 131188

llvm-svn: 131187

This change allows bugpoint to pinpoint the "opt" pass and bitcode
segment responsible for a crash caused by miscompilation. At least it
works well for me now, without having to create any custom execution
wrappers.

llvm-svn: 131186

Add ability to recognize/handle quotes around commands
(e.g. '"target" create'  works as well as 'target create').

llvm-svn: 131185

llvm-svn: 131184

Fixes a bug in the DAGCombiner.  LoadSDNodes have two values (data, chain).
If there is a store after the load node, then there is a chain, which means
that there is another user. Thus, asking hasOneUser would fail. Instead we
ask hasNUsesOfValue on the 'data' value.

llvm-svn: 131183

gcc.

Fixes PR9886.

llvm-svn: 131182

gcc.

Fixes PR9886.

llvm-svn: 131181

Add custom lowering of X86 vector SRA/SRL/SHL when the shift amount is a splat vector.

llvm-svn: 131179

then teach -Wreturn-type to handle the same.  Net effect:  we now correctly
handle noreturn attributes on member calls in the CFG.

llvm-svn: 131178

dynamic_cast correctly.

llvm-svn: 131177

to provide a reduced testcase.

llvm-svn: 131176

This removes 2 errors when parsing MFC code with clang

Example:
class A {
    virtual void f() = 0 { }
}

llvm-svn: 131175

intrinsic call. This prevents it from being reordered so that it appears
*before* the setjmp intrinsic (thus making it completely useless).
<rdar://problem/9409683>

llvm-svn: 131174

llvm-svn: 131173

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: 131170

llvm-svn: 131169

llvm-svn: 131168

llvm-svn: 131165

llvm-svn: 131164

llvm-svn: 131162

llvm-svn: 131161

llvm-svn: 131160

headers.

llvm-svn: 131159

llvm-svn: 131158

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

compile unit, which has an external reference to symbols defined in foo.m, the type query:

    in this case, 'expression (NSArray*)array_token'

continues to work.

This test is to accompany http://llvm.org/viewvc/llvm-project?rev=131145&view=rev.

llvm-svn: 131154

that they are C++0x extensions, and put them in the appropriate
group. We already support most of the semantics. Addresses
<rdar://problem/9407525>.

llvm-svn: 131153

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