Until now all debug info MDNodes referred to a root MDNode, a compile unit. This simplified handling of these needs in dwarf writer.  However, one side effect of this is that during link time optimization all these MDNodes are _not_ uniqued. In other words there will be N number of MDNodes describing "int", "char" and all other types, which would suddenly grow when each object file starts using libraries like STL.

MDNodes graph structure such that compiler unit keeps track of important MDNodes and update dwarf writer to process mdnodes top-down instead of bottom up.

llvm-svn: 137778

llvm-svn: 137728

llvm-svn: 137689

llvm-svn: 137683

llvm-svn: 137668

llvm-svn: 137663

There is no need to maintain a set to keep track of variables that use location expressions. In such cases, AT_location attribute's value will be a label.

llvm-svn: 137659

llvm-svn: 137658

llvm-svn: 137656

When a variable is inlined multiple places, abstract variable keeps name, location, type etc.. info and all other concreate instances of the variable directly refers to abstract variable.

llvm-svn: 137637

llvm-svn: 137632

llvm-svn: 137631

llvm-svn: 137621

llvm-svn: 137618

llvm-svn: 137485

llvm-svn: 137321

llvm-svn: 137283

Distinguish between two copies of one inlined variable. Take 2.

llvm-svn: 137253

llvm-svn: 137249

llvm-svn: 137246

llvm-svn: 137056

inlined variable, based on the discussion in PR10542.

This explodes the runtime of several passes down the pipeline due to
a large number of "copies" remaining live across a large function. This
only shows up with both debug and opt, but when it does it creates
a many-minute compile when self-hosting LLVM+Clang. There are several
other cases that show these types of regressions.

All of this is tracked in PR10542, and progress is being made on fixing
the issue. Once its addressed, the re-instated, but until then this
restores the performance for self-hosting and other opt+debug builds.

Devang, let me know if this causes any trouble, or impedes fixing it in
any way, and thanks for working on this!

llvm-svn: 136953

llvm-svn: 136802

llvm-svn: 136759

lines. No functionality change.

llvm-svn: 136458

llvm-svn: 136275

It is quiet possible that inlined function body is split into multiple chunks of consequtive instructions. But, there is not any way to describe this in .debug_inline accelerator table used by gdb. However, describe non contiguous ranges of inlined function body appropriately using AT_range of DW_TAG_inlined_subroutine debug info entry.

llvm-svn: 136196

While extracting lexical scopes from machine instruction stream, work on one machine basic block at a time. 

llvm-svn: 136106

llvm-svn: 135633

There are two ways to map a variable to its lexical scope. Lexical scope information is embedded in MDNode describing the variable. It is also available as a part of DebugLoc attached with DBG_VALUE instruction. DebugLoc attached with an instruction is less reliable in optimized code so use information embedded in the MDNode.

llvm-svn: 135629

llvm-svn: 135528

llvm-svn: 135302

llvm-svn: 135278

llvm-svn: 135254

llvm-svn: 135232

llvm-svn: 135212

Improve DbgScope->dump() output.

llvm-svn: 135207

llvm-svn: 135127

llvm-svn: 135124

llvm-svn: 135118