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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211852 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201535 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193233 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191835 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191823 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191670 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189415 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189125 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188921 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184924 91177308-0d34-0410-b5e6-96231b3b80d8
Archive files (.a) can have a symbol table indicating which object
files in them define which symbols. The purpose of this symbol table
is to speed up linking by allowing the linker the read only the .o
files it is actually going to use instead of having to parse every
object's symbol table.
LLVM's archive library currently supports a LLVM specific format for
such table. It is hard to see any value in that now that llvm-ld is
gone:
* System linkers don't use it: GNU ar uses the same plugin as the
linker to create archive files with a regular index. The OS X ar
creates no symbol table for IL files, I assume the linker just parses
all IL files.
* It doesn't interact well with archives having both IL and native objects.
* We probably don't want to be responsible for yet another archive
format variant.
This patch then:
* Removes support for creating and reading such index from lib/Archive.
* Remove llvm-ranlib, since there is nothing left for it to do.
We should in the future add support for regular indexes to llvm-ar for
both native and IL objects. When we do that, llvm-ranlib should be
reimplemented as a symlink to llvm-ar, as it is equivalent to "ar s".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184019 91177308-0d34-0410-b5e6-96231b3b80d8
- if you have LLDB checked out in $llvm/tools, CMake will build it now!
- LLDB is known to build on Linux with libstdc++ and GCC 4.6/4.7 or Clang 3.3
- to run lldb tests, do "make check-lldb" after a build
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176307 91177308-0d34-0410-b5e6-96231b3b80d8
This is the second and last (2/2) part of a change that moves llvm-symbolizer to llvm/tools/, which will allow to build it
with both cmake and configure+make.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167723 91177308-0d34-0410-b5e6-96231b3b80d8
While making lld build under the tools directory I decided to refactor how this
works.
There is now a macro, add_llvm_external_project, which takes the name of the
expected subdirectory. This sets up two CMake options.
* LLVM_EXTERNAL_${NAME}_SOURCE_DIR
This is the path to the source. It defaults to
${CMAKE_CURRENT_SOURCE_DIR}/${name}.
* LLVM_EXTERNAL_${NAME}_BUILD
Enable and disable building the tool as part of LLVM.
I chose LLVM_EXTERNAL_${NAME} as a prefix so they all show up together in the
GUI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155654 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-ld is no longer useful and causes confusion and so it is being removed.
* Does not work very well on Windows because it must call a gcc like driver to
assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
ld, or fully replaced by Clang.
I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155147 91177308-0d34-0410-b5e6-96231b3b80d8
* Add begin_dynamic_table() / end_dynamic_table() private interface to ELFObjectFile.
* Add begin_libraries_needed() / end_libraries_needed() interface to ObjectFile, for grabbing the list of needed libraries for a shared object or dynamic executable.
* Implement this new interface completely for ELF, leave stubs for COFF and MachO.
* Add 'llvm-readobj' tool for dumping ObjectFile information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151785 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
llvm-config: Replace with C++ version (was llvm-config-2).
- Reapply of r144300, with lots of fixes/migration easement in between.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145582 91177308-0d34-0410-b5e6-96231b3b80d8
for now).
- Mostly complete except for the data that needs to come from the build system
or the dependencies.
- Has some small improvements from current llvm-config:
o Uses TargetRegistry directly to get some information.
o Designed to work correctly when used from a CMake build tree (relatively
untested currently) (although pcc fixed this recently for old llvm-config).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143616 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces a new library to LLVM: libDebugInfo. It will provide debug information
parsing to LLVM. Much of the design and some of the code is taken from the LLDB project.
It also contains an llvm-dwarfdump tool that can dump the abbrevs and DIEs from an
object file. It can be used to write tests for DWARF input and output easily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139627 91177308-0d34-0410-b5e6-96231b3b80d8
available when Clang is found within the LLVM tree. If enabled (the
default), Clang will be built as part of LLVM. If disabled, Clang will
be skipped... and can be built by configuring a separate object
directory just for Clang. This helps break up the monolithic
LLVM+Clang project that many Clang developers use, improving
build/load times.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135218 91177308-0d34-0410-b5e6-96231b3b80d8
Add a bone-simple utility to load a MachO object into memory, look for
a function (main) in it, and run that function directly. This will be used
as a test and development platform for MC-JIT work regarding symbol resolution,
dynamic lookup, etc..
Code by Daniel Dunbar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127885 91177308-0d34-0410-b5e6-96231b3b80d8
