Do not use named md nodes to track variables that are completely optimized. This does not scale while doing LTO with debug info. New approach is to include list of variables in the subprogram info directly.

llvm-svn: 138145

The irony is not lost that this is not a completely trivial patchset.

llvm-svn: 138143

needed for Mips32.

llvm-svn: 138132

llvm-svn: 138131

llvm-svn: 138130

llvm-svn: 138125

llvm-svn: 138124

a bug and add a testcase!

llvm-svn: 138123

llvm-svn: 138116

llvm-svn: 138108

llvm-svn: 138102

llvm-svn: 138091

llvm-svn: 138076

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

llvm-svn: 138063

llvm-svn: 138061

llvm-svn: 138060

llvm-svn: 138059

MCParsedAsmOperand objects were being leaked.

llvm-svn: 138053

llvm-svn: 138052

llvm-svn: 138050

llvm-svn: 138048

llvm-svn: 138047

llvm-svn: 138042

module.

Patch by Pekka Jääskeläinen.

llvm-svn: 138037

llvm-svn: 138034

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

SplitLandingPadPredecessors is similar to SplitBlockPredecessors in that it
splits the current block and attaches a set of predecessors to the new basic
block. However, it differs from SplitBlockPredecessors in that it's specifically
designed to handle landing pad blocks.

Two new basic blocks are created: one that is has the vector of predecessors as
its predecessors and one that has the remaining predecessors as its
predecessors. Those two new blocks then receive a cloned copy of the landingpad
instruction from the original block. The landingpad instructions are joined in a
PHI, etc. Like SplitBlockPredecessors, it updates the LLVM IR, AliasAnalysis,
DominatorTree, DominanceFrontier, LoopInfo, and LCCSA analyses.

llvm-svn: 138014

instead of 2. They were already defined this way in their regular
version, but not for the intrinsics versions (*_Int), and that would work
for assembly emission but not for object code, since a MachineOperand
would be missing. This commit fix PR10697.

Also removed the {VSQRT,VRSQRT,VRCP}r_Int forms and match the intrinsic
via INSERT_SUBREG+EXTRACT_SUBREG patterns. The same couldn't be done for
memory versions because sse_load_f32/sse_load_f64 operand need special
handling and don't work like regular "addr" operands.

There are right now 114 "*_Int" and 98 "Int_*" forms! I'm slowly
removing them as I step through, but hope we can get rid of these
someday, they are really annoying :)

llvm-svn: 138012

There is no need to add file as context for subroutine type. The subroutine type does not need any context.

llvm-svn: 138010

add the comments of each declaration follow it, making it easier to read and compare to GCC's result.

llvm-svn: 138009

llvm-svn: 138008