Commit Graph

103 Commits

Author SHA1 Message Date
Tobias Grosser fee94ff8a9 Remove leftover
llvm-svn: 268049
2016-04-29 15:08:05 +00:00
Tobias Grosser d7773f7209 cmake: Set LINK_POLLY_INTO_TOOLS to ON (v2)
This is the second try. This time we disable this feature if no Polly checkout
is available. For this to work we need to check if tools/polly is present
early enough that our decision is known before cmake generates Config/config.h.

With Polly checked into LLVM it was since a long time possible to compile
clang/opt/bugpoint with Polly support directly linked in, instead of only
providing Polly as a separate loadable module. This commit switches the
default from providing Polly as a module to linking Polly into tools, such
that it becomes unnecessary to load the Polly module when playing with Polly.
Such configuration has shown a lot more convenient for day-to-day Polly use.

This change does not impact the default behavior of any tool, if Polly is not
explicitly enabled when calling clang/opt/bugpoint Polly does not affect
compilation.

This change also does not impact normal LLVM/clang checkouts that do not
contain Polly.

Reviewers: jdoerfert, Meinersbur

Subscribers: pollydev, llvm-commits

Differential Revision: http://reviews.llvm.org/D19711

llvm-svn: 268048
2016-04-29 15:07:22 +00:00
Chris Bieneman e50f744743 [CMake] Add the gold plugin before clang
This is needed to connect dependencies between the LLVMgold plugin and the clang stage-2 builds due to limitations in ExternalProject_Add.

Patch by Mike Edwards

Differential Revision: http://reviews.llvm.org/D17655

llvm-svn: 262067
2016-02-26 21:07:04 +00:00
Hans Wennborg f6892eda24 [CMake] don't build libLTO when LLVM_ENABLE_PIC is OFF
When cmake is run with -DLLVM_ENABLE_PIC=OFF, build fails while
linking shared library libLTO.so, because its dependencies are built
with -fno-PIC. More details here: https://llvm.org/bugs/show_bug.cgi?id=26484.
This diff reverts r252652 (git 9fd4377ddb83aee3c049dc8757e7771edbb8ee71),
which removed check NOT LLVM_ENABLE_PIC before disabling build for libLTO.so.

Patch by Igor Sugak!

Differential Revision: http://reviews.llvm.org/D17049

llvm-svn: 260703
2016-02-12 19:02:39 +00:00
Chris Bieneman d6f5f24a29 [CMake] Adding llvm-profdata to the list of tools clang needs.
Bootstrapping clang to generate PGO data (patches coming soon), requires llvm-profdata targets to be generated before clang.

llvm-svn: 255794
2015-12-16 18:30:36 +00:00
Chris Bieneman 3809ca9d00 [CMake] Autoconf builds libLTO with -fPIC, CMake should be able to as well.
llvm-svn: 252652
2015-11-10 21:38:58 +00:00
Chris Bieneman 042e817bff [CMake] We need to explicitly add llvm-config before clang so that LLVM_BUILD_EXTERNAL_COMPILER_RT can depend on llvm-config.
This patch is a required stepping stone to fix PR14109.

llvm-svn: 249202
2015-10-02 22:28:48 +00:00
Chris Bieneman de9588e049 [CMake] Add llvm-ar subdirectory explicitly.
This is required because ExternalProject_Add requires all targets specified in the DEPENDS argument must exist before calling ExternalProject_Add.

llvm-svn: 247592
2015-09-14 18:36:40 +00:00
Chris Bieneman 7ad7ae1fac [CMake] Add lto subdirectory explicitly.
This is required because ExternalProject_Add requires all targets specified in the DEPENDS argument must exist before calling ExternalProject_Add.

I have a follow-up patch to clang that enables using the just-built libLTO in bootstrap builds, so we need to be able to add the LTO target as a dependency in clang.

llvm-svn: 247316
2015-09-10 18:22:33 +00:00
Chris Bieneman 19d42692e7 [CMake] Projects supported via LLVM_EXTERNAL_*_SOURCE_DIR need to be explicitly specified.
One part of my refactoring from r242705 is untenable due to how CMake caches variables. There is no way other than caching to allow variables to be set in one directory and globally readable, but we really don't want to cache the temporary value marking that a directory has already been included.

llvm-svn: 242793
2015-07-21 15:53:09 +00:00
Chris Bieneman 580d8159d5 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Re-landing r242059 which re-landed r241621... I'm really bad at this.

Summary (r242059):
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.

Summary (r241621):
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 242705
2015-07-20 20:36:06 +00:00
Chris Bieneman 86b1fd77e6 Revert "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working."
Reverting r242059 because it broke some bots. I'm attempting to reproduce the failures now.

llvm-svn: 242060
2015-07-13 20:30:58 +00:00
Chris Bieneman 8ac6d119b7 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Summary:
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.

Original Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 242059
2015-07-13 20:23:15 +00:00
NAKAMURA Takumi 58843eede5 Revert r241621, "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working."
It broke the build that relies on LLVM_EXTERNAL_CLANG_*.

llvm-svn: 241663
2015-07-08 02:35:43 +00:00
Chris Bieneman 3765588f65 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables
* removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Reviewers: bogner, samsonov, chapuni, beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 241621
2015-07-07 20:24:55 +00:00
Chris Bieneman 69533a5a85 [CMake] Treating LLVM_INCLUDE_TOOLS, which is a bool, as a string to change behaviors of the build is a dirty hack. We shouldn't do it.
Summary: I don't think anyone is relying on this behavior for bootstrapping (because I don't think it works), but if you do need it, speak now or forever hold your peace.

Reviewers: chapuni, samsonov

Reviewed By: samsonov

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10613

llvm-svn: 240344
2015-06-22 21:58:02 +00:00
David Majnemer f45bbd0da3 llvm-cxxdump: Rename llvm-vtabledump to llvm-cxxdump
llvm-vtabledump has grown enough functionality not related to vtables
that it deserves a name which is more descriptive.

llvm-svn: 232301
2015-03-15 01:30:58 +00:00
Zachary Turner a5549178f1 Rewrite llvm-pdbdump in terms of LLVMDebugInfoPDB.
This makes llvm-pdbdump available on all platforms, although it
will currently fail to create a dumper if there is no PDB reader
implementation for the current platform.

It implements dumping of compilands and children, which is less
information than was previously available, but it has to be
rewritten from scratch using the new set of interfaces, so the
rest of the functionality will be added back in subsequent commits.

llvm-svn: 228755
2015-02-10 22:43:25 +00:00
Andrew Kaylor d4b80b8e68 Really, really, really don't build llvm-pdbdump on MSVC < 2013.
There was a typo in the last attempt.

llvm-svn: 227937
2015-02-03 03:08:25 +00:00
Zachary Turner 6037dcfb8b Really really don't build llvm-pdbdump on MSVC < 2013.
I thought it was enough to just not add the tool subdirectory,
but apparently I need to explicitly mark it ignore.

llvm-svn: 227587
2015-01-30 18:08:05 +00:00
Zachary Turner d5bb7e142b Disable compilation of llvm-pdbdump for versions of MSVC < 2013.
Certain aspects of llvm-pdbdump require language support only present in
MSVC 2013 and higher.  Since this is strictly a utility, and since we hope
to drop support for MSVC 2012 soon, don't build this unless MSVC 2013 or
higher.

llvm-svn: 227479
2015-01-29 18:44:14 +00:00
Zachary Turner fcb14ad7a3 Add llvm-pdbdump to tools.
llvm-pdbdump is a tool which can be used to dump the contents
of Microsoft-generated PDB files.  It makes use of the Microsoft
DIA SDK, which is a COM based library designed specifically for
this purpose.

The initial commit of this tool dumps the raw bytes from PDB data
streams.  Future commits will dump more semantic information such
as types, symbols, source files, etc similar to the types of
information accessible via llvm-dwarfdump.

Reviewed by: Aaron Ballman, Reid Kleckner, Chandler Carruth
Differential Revision: http://reviews.llvm.org/D7153

llvm-svn: 227241
2015-01-27 20:46:21 +00:00
Frederic Riss 231f714e54 Initial dsymutil tool commit.
The goal of this tool is to replicate Darwin's dsymutil functionality
based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does
not link the debug information, it leaves it in the object files in
relocatable form, but embbeds a `debug map` into the executable that
describes where to find the debug information and how to relocate it.
When releasing/archiving a binary, dsymutil is called to link all the DWARF
information into a `dsym bundle` that can distributed/stored along with
the binary.

With this commit, the LLVM based dsymutil is just able to parse the STABS
debug maps embedded by ld64 in linked binaries (and not all of them, for
example archives aren't supported yet).

Note that the tool directory is called dsymutil, but the executable is
currently called llvm-dsymutil. This discrepancy will disappear once the
tool will be feature complete. At this point the executable will be renamed
to dsymutil, but until then you do not want it to override the system one.

    Differential Revision: http://reviews.llvm.org/D6242

llvm-svn: 224134
2014-12-12 17:31:24 +00:00
Frederic Riss 04aef05537 Revert "Initial dsymutil tool commit."
This reverts commit r223793. The review thread wasn't concluded.

llvm-svn: 223794
2014-12-09 17:21:50 +00:00
Frederic Riss 893c4f1e4d Initial dsymutil tool commit.
The goal of this tool is to replicate Darwin's dsymutil functionality
based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does
not link the debug information, it leaves it in the object files in
relocatable form, but embbeds a `debug map` into the executable that
describes where to find the debug information and how to relocate it.
When releasing/archiving a binary, dsymutil is called to link all the DWARF
information into a `dsym bundle` that can distributed/stored along with
the binary.

With this commit, the LLVM based dsymutil is just able to parse the STABS
debug maps embedded by ld64 in linked binaries (and not all of them, for
example archives aren't supported yet).

Note that the tool directory is called dsymutil, but the executable is
currently called llvm-dsymutil. This discrepancy will disappear once the
tool will be feature complete. At this point the executable will be renamed
to dsymutil, but until then you do not want it to override the system one.

    Differential Revision: http://reviews.llvm.org/D6242

llvm-svn: 223793
2014-12-09 17:03:30 +00:00
Rafael Espindola 9c8ebeb03d Be less conservative about when we build the gold plugin.
It is only build if LLVM_BINUTILS_INCDIR is explicitly given, so there is
no point in having extra restrictions.

llvm-svn: 223481
2014-12-05 17:25:52 +00:00
Peter Collingbourne a4f0bd7857 Teach LLVM about llgo subproject.
llvm-svn: 222860
2014-11-27 00:15:21 +00:00
NAKAMURA Takumi e1e5274a88 [CMake] Move llvm-shlib in prior to other tools.
llvm-svn: 221590
2014-11-10 15:03:02 +00:00
Chris Bieneman adffd01498 Adding llvm-shlib to CMake build system with a few new bells and whistles
Summary:
This patch adds a new CMake build setting LLVM_BUILD_LLVM_DYLIB, which defaults to OFF. When set to ON, this will generate a shared library containing most of LLVM. The contents of the shared library can be overriden by specifying LLVM_DYLIB_COMPONENTS. LLVM_DYLIB_COMPONENTS can be set to a semi-colon delimited list of any LLVM components that you llvm-config can resolve.

On Windows, unless you are using Cygwin, you must specify an explicit symbol export file using LLVM_EXPORTED_SYMBOL_FILE. On Cygwin and all unix-like platforms if you do not specify LLVM_EXPORTED_SYMBOL_FILE, an export file containing only the LLVM C API will be auto-generated from the list of LLVM components specified in LLVM_DYLIB_COMPONENTS.

Reviewers: rnk

Reviewed By: rnk

Subscribers: rnk, llvm-commits

Differential Revision: http://reviews.llvm.org/D5890

llvm-svn: 220490
2014-10-23 17:22:14 +00:00
Peter Collingbourne 244ecf55bd Add llvm-go tool.
This tool lets us build LLVM components within the tree by setting up a
$GOPATH that resembles a tree fetched in the normal way with "go get".

It is intended that components such as the Go frontend will be built in-tree
using this tool.

Differential Revision: http://reviews.llvm.org/D5902

llvm-svn: 220462
2014-10-23 02:33:23 +00:00
Duncan P. N. Exon Smith a12e023c8a Rename llvm-uselistorder => verify-uselistorder
llvm-svn: 214318
2014-07-30 17:11:27 +00:00
Duncan P. N. Exon Smith 4b4d8ecde1 Move -verify-use-list-order into llvm-uselistorder
Ugh.  Turns out not even transformation passes link in how to read IR.
I sincerely believe the buildbots will finally agree with my system
after this though.  (I don't really understand why all of this has been
working on my system, but not on all the buildbots.)

Create a new tool called llvm-uselistorder to use for verifying use-list
order.  For now, just dump everything from the (now defunct)
-verify-use-list-order pass into the tool.

This might be a better way to test use-list order anyway.

Part of PR5680.

llvm-svn: 213957
2014-07-25 17:13:03 +00:00
David Majnemer 72ab1a5aee llvm-vtabledump: A vtable dumper
This tool's job is to dump the vtables inside object files.  It is
currently limited to MS ABI vf- and vb-tables but it will eventually
support Itanium-style v-tables as well.

Differential Revision: http://reviews.llvm.org/D4584

llvm-svn: 213903
2014-07-24 23:14:40 +00:00
Rafael Espindola 3ef98ff5f9 Don't force the build of toos/lto as a static lib.
Any uses of tools/lto as a static lib should probably move to lib/LTO.
This was also never implemented in the configure build, so this reduces
the differences among the two.

llvm-svn: 211852
2014-06-27 02:51:21 +00:00
Sebastian Pop a59005be81 static link polly into tools
llvm-svn: 203886
2014-03-14 04:04:14 +00:00
Sebastian Pop 02a0dd8dd1 fix polly buildbot
llvm-svn: 203492
2014-03-10 21:27:04 +00:00
Sebastian Pop e3cd1429e5 fix PR13550: add a cmake WITH_POLLY option
llvm-svn: 203486
2014-03-10 20:47:39 +00:00
NAKAMURA Takumi c886295343 Remove out-of-date comment in llvm/tools/CMakeLists.txt.
llvm-svn: 202857
2014-03-04 16:13:21 +00:00
Duncan P. N. Exon Smith 846a627f5c PGO: llvm-profdata: tool for merging profiles
Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.

- The name indicates a file extension of <name>.profdata.  Eventually
  profile data output by clang should be changed to that extension.

- llvm-profdata merges two profiles.  However, the name is more general,
  since it will likely pick up more tasks (such as summarizing a single
  profile).

- llvm-profdata parses the current text-based format, but will be
  updated once we settle on a binary format.

<rdar://problem/15949645>

llvm-svn: 201535
2014-02-17 23:22:49 +00:00
NAKAMURA Takumi 07a6406444 llvm/tools/llvm-c-test should be built also on msvc.
llvm-svn: 193257
2013-10-23 17:56:59 +00:00
Anders Waldenborg b932c66955 Add llvm-c-test tool for testing llvm-c
This provides rudimentary testing of the llvm-c api.

The following commands are implemented:

  * --module-dump
    Read bytecode from stdin - print ir

  * --module-list-functions
    Read bytecode from stdin - list summary of functions

  * --module-list-globals
    Read bytecode from stdin - list summary of globals

  * --targets-list
    List available targets

  * --object-list-sections
    Read object file from stdin - list sections

  * --object-list-symbols
    Read object file from stdin - list symbols (like nm)

  * --disassemble
    Read lines of triple, hex ascii machine code from stdin - print disassembly

  * --calc
    Read lines of name, rpn from stdin - print generated module ir

Differential-Revision: http://llvm-reviews.chandlerc.com/D1776
llvm-svn: 193233
2013-10-23 08:10:20 +00:00
Chandler Carruth ea56494625 Remove the very substantial, largely unmaintained legacy PGO
infrastructure.

This was essentially work toward PGO based on a design that had several
flaws, partially dating from a time when LLVM had a different
architecture, and with an effort to modernize it abandoned without being
completed. Since then, it has bitrotted for several years further. The
result is nearly unusable, and isn't helping any of the modern PGO
efforts. Instead, it is getting in the way, adding confusion about PGO
in LLVM and distracting everyone with maintenance on essentially dead
code. Removing it paves the way for modern efforts around PGO.

Among other effects, this removes the last of the runtime libraries from
LLVM. Those are being developed in the separate 'compiler-rt' project
now, with somewhat different licensing specifically more approriate for
runtimes.

llvm-svn: 191835
2013-10-02 15:42:23 +00:00
Rafael Espindola d38f9af213 Enable building LTO on WIN32.
Enable building the LTO library (.lib and.dll) and llvm-lto.exe on Windows with
MSVC and Mingw as well as re-enabling the associated test.

Patch by Greg Bedwell!

llvm-svn: 191823
2013-10-02 14:04:38 +00:00
Rafael Espindola cbef8e60e3 Revert "Enable building LTO on WIN32."
This reverts commit r191670.

It was causing build failures on the msvc bots:

http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/5166/steps/compile/logs/stdio

llvm-svn: 191679
2013-09-30 16:32:51 +00:00
Rafael Espindola e693181c10 Enable building LTO on WIN32.
Enable building the LTO library (.lib and.dll) and llvm-lto.exe on Windows with
MSVC and Mingw as well as re-enabling the associated test.

Patch by Greg Bedwell!

llvm-svn: 191670
2013-09-30 15:28:14 +00:00
Peter Collingbourne 4e380b0a04 Fix LTO handling of module-level assembly (PR14152).
Patch by Tom Roeder!

llvm-svn: 191042
2013-09-19 22:15:52 +00:00
Argyrios Kyrtzidis dba67a226f [CMake] Put back the add_llvm_external_project() calls for specific projects.
This allows setting-up the LLVM_EXTERNAL_* CMake variables that some people are using,
e.g. to set the source directory of the project in a different place.

llvm-svn: 189415
2013-08-27 23:27:56 +00:00
Hans Wennborg fe06e811a3 CMake: build llvm-config on Windows.
It was previously not being built on Windows because the cmake file relied
on a sed script to generate a .in file that llvm-config needs.

By using cmake's configure_file function, we can get rid off the sed hack,
and also have this work on Windows.

Differential Revision: http://llvm-reviews.chandlerc.com/D1481

llvm-svn: 189125
2013-08-23 17:59:13 +00:00
Argyrios Kyrtzidis 7eec9d0c04 [CMake] Automatically pick up subdirectories in llvm/tools as 'external projects' if they contain a 'CMakeLists.txt' file.
Allow CMake to pick up external projects in llvm/tools without the need to modify the "llvm/tools/CMakeLists.txt" file.
This makes it easier to work with projects that live in other repositories, without needing to specify each one in "llvm/tools/CMakeLists.txt".

llvm-svn: 188921
2013-08-21 19:13:44 +00:00
Andy Gibbs 3ef5ed1ec0 Provide bootstrap support to build only llvm+clang when using cmake.
Where a source tree is complete with lld, lldb and polly, it may not be possible to use cmake to configure build scripts if the host compiler it not capable of compiling these sub-projects.  This change makes it possible to first build a bootstrap clang compiler when can then be used to build a complete llvm toolchain.  An example bootstrap build sequence could be as follows:

$ mkdir bootstrap
$ cd bootstrap
$ cmake -G 'Unix Makefiles'
        -DCMAKE_BUILD_TYPE:STRING=Release
        -DCMAKE_PREFIX_PATH:STRING=$(pwd)
        -DLLVM_TARGETS_TO_BUILD:STRING=host
        -DLLVM_INCLUDE_TOOLS:STRING=bootstrap-only
        ../source
$ make clang  # build clang only for host

$ cd ..
$ export CC=$(realpath bootstrap/bin)/clang
$ export CXX=$(realpath bootstrap/bin)/clang++

$ mkdir final
$ cd final
$ cmake -G 'Unix Makefiles' ../source
$ make all check-all

llvm-svn: 184924
2013-06-26 08:05:08 +00:00