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

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

llvm-svn: 138009

llvm-svn: 138006

llvm-svn: 137998

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

The argument is unused, and is a layering violation in any case.

llvm-svn: 137735

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

llvm-svn: 136609

lines. No functionality change.

llvm-svn: 136458

specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.

I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.

This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.

This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.

Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.

This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.

llvm-svn: 136433

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

Rename TargetAsmParser to MCTargetAsmParser and TargetAsmLexer to MCTargetAsmLexer; rename createAsmLexer to createMCAsmLexer and createAsmParser to createMCAsmParser.

llvm-svn: 136027

llvm-svn: 135833

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

While emitting constant value, look through derived type and use underlying basic type to determine size and signness of the constant value.

llvm-svn: 135627