llvm-svn: 138101

llvm-svn: 138100

llvm-svn: 138091

llvm-svn: 138087

llvm-svn: 138086

llvm-svn: 138085

llvm-svn: 138084

llvm-svn: 138083

an opt test.

llvm-svn: 138082

llvm-svn: 138077

llvm-svn: 138076

llvm-svn: 138073

llvm-svn: 138072

the intent seems to be to terminate even in Release builds, just use abort()
directly.

If program flow ever reaches a __builtin_unreachable (which llvm_unreachable is
#define'd to on newer GCCs) then the program is undefined.

llvm-svn: 138068

llvm-svn: 138067

llvm-svn: 138066

llvm-svn: 138065

llvm-svn: 138064

llvm-svn: 138063

llvm-svn: 138061

llvm-svn: 138060

llvm-svn: 138059

llvm-svn: 138056

MCParsedAsmOperand objects were being leaked.

llvm-svn: 138053

llvm-svn: 138052

llvm-svn: 138050

llvm-svn: 138048

llvm-svn: 138047

commas.

llvm-svn: 138043

llvm-svn: 138042

module.

Patch by Pekka Jääskeläinen.

llvm-svn: 138037

llvm-svn: 138034

llvm-svn: 138033

implementation!

llvm-svn: 138029

This is useful for unit tests.

llvm-svn: 138028

llvm-svn: 138025

C API functions must be able to see their extern "C" definitions, or it will be impossible to call them from C.

llvm-svn: 138022

Normally, a partial register def is treated as reading the
super-register unless it also defines the full register like this:

  %vreg110:sub_32bit<def> = COPY %vreg77:sub_32bit, %vreg110<imp-def>

This patch also uses the <undef> flag on partial defs to recognize
non-reading operands:

  %vreg110:sub_32bit<def,undef> = COPY %vreg77:sub_32bit

This fixes a subtle bug in RegisterCoalescer where LIS->shrinkToUses
would treat a coalesced copy as still reading the register, extending
the live range artificially.

My test case only works when I disable DCE so a dead copy is left for
RegisterCoalescer, so I am not including it.

<rdar://problem/9967101>

llvm-svn: 138018

known-incremented level, because the two concepts can be used
to prove the saftey of a retain+release removal in different
ways.

llvm-svn: 138016

We have to be careful when splitting the landing pad block, because the
landingpad instruction is required to remain as the first non-PHI of an invoke's
unwind edge. To retain this, we split the block into two blocks, moving the
predecessors within the loop to one block and the remaining predecessors to the
other. The landingpad instruction is cloned into the new blocks.

llvm-svn: 138015