maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
218,449 Commits 23 Branches 0 Tags 2.2 GiB
Commit Graph

214 Commits

Author SHA1 Message Date
Eric Christopher 0dab36478a Add a field to the compile unit of where we plan on splitting out 
the debug info for -gsplit-dwarf so we can encode that location
in the skeleton cu.

llvm-svn: 175933
 2013-02-22 23:50:04 +00:00
Eric Christopher 8952471328 Add a TODO and explain when we can get rid of the isMain field. 
llvm-svn: 175932
 2013-02-22 23:50:01 +00:00
David Blaikie 12bbf715fc DIBuilder: Correct the null/0 type of trailing fields in struct debug info. 
Paired with an Clang commit so this may cause temporary build failures.

llvm-svn: 175426
 2013-02-18 07:27:30 +00:00
David Blaikie 595eb44a2c DIBuilder: Add function and method definitions to the list of all subprograms 
Previously we seemed to be assuming that all functions were definitions and all
methods were declarations. This may be consistent with how Clang uses DIBuilder
but doesn't have to be true of all clients (such as DragonEgg).

llvm-svn: 175423
 2013-02-18 07:10:22 +00:00
David Blaikie f11de2f27d Narrow the return types of a few DIBuilder utility functions. 
llvm-svn: 175421
 2013-02-18 06:41:57 +00:00
David Blaikie 209d63af48 DIBuilder: make the return type of createBasicType more specific 
llvm-svn: 174924
 2013-02-12 00:40:41 +00:00
David Blaikie 2811f8ac28 [DebugInfo] remove more node indirection (this time from the subprogram's variable lists) 
llvm-svn: 174305
 2013-02-04 05:56:36 +00:00
David Blaikie 33111dfea0 Remove the (apparently) unnecessary debug info metadata indirection. 
The main lists of debug info metadata attached to the compile_unit had an extra
layer of metadata nodes they went through for no apparent reason. This patch
removes that (& still passes just as much of the GDB 7.5 test suite). If anyone
can show evidence as to why these extra metadata nodes are there I'm open to
reverting this patch & documenting why they're there.

llvm-svn: 174266
 2013-02-02 05:56:24 +00:00
Eric Christopher 4d23a4ae1f Define metadata interfaces for describing a static data member 
of a class. Emit static data member declarations and definitions
through correctly.

Part of PR14471.

Patch by Paul Robinson!

llvm-svn: 172590
 2013-01-16 01:22:23 +00:00
Eric Christopher 72a529566c Remove the llvm-local DW_TAG_vector_type tag and add a test to 
make sure that vector types do work.

llvm-svn: 171833
 2013-01-08 01:53:52 +00:00
Eric Christopher 9bd3609a08 Fix comment. 
llvm-svn: 171832
 2013-01-08 01:53:42 +00:00
David Blaikie 5d3249b554 PR14759: Debug info support for C++ member pointers. 
This works fine with GDB for member variable pointers, but GDB's support for
member function pointers seems to be quite unrelated to
DW_TAG_ptr_to_member_type. (see GDB bug 14998 for details)

llvm-svn: 171698
 2013-01-07 05:51:15 +00:00
Chandler Carruth 9fb823bbd4 Move all of the header files which are involved in modelling the LLVM IR 
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366
 2013-01-02 11:36:10 +00:00
Chandler Carruth ef860a2488 Rename VMCore directory to IR. 
Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

llvm-svn: 171359
 2013-01-02 09:10:48 +00:00