Add LLVM_USE_NEWPM to build LLVM using the experimental new pass manager.

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

llvm-svn: 353550

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 353374

Reverting D57264 again, it looks like we're down to two bots that need fixing:

polly-amd64-linux
polly-arm-linux

They both have old versions of libstdc++ and recent clang.

llvm-svn: 352954

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352951

Looks like we still have a few bots that are sad. Let try to get them fixed!

llvm-svn: 352835

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352834

A handful of bots are still breaking, either because I missed them in my audit,
they were offline, or something else. I'm contacting their authors, but I'll
revert for now and re-commit later.

llvm-svn: 352814

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352811

Summary: This change factors out compiler checking / warning, and documents LLVM_FORCE_USE_OLD_TOOLCHAIN. It doesn't introduce any functional changes nor policy changes, these will come late.

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits

Differential Revision: https://reviews.llvm.org/D56799

llvm-svn: 351387

Differential Revision: https://reviews.llvm.org/D56302

llvm-svn: 350400

Summary:
This function is very similar to add_llvm_library(),  so this patch merges it
into add_llvm_library() and replaces all calls to add_llvm_loadable_module(lib ...)
with add_llvm_library(lib MODULE ...)

Reviewers: philip.pfaffe, beanz, chandlerc

Reviewed By: philip.pfaffe

Subscribers: chapuni, mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D51748

llvm-svn: 349839

The assertion in MCCodeView.cpp was resolved in r340878.

This reverts both r340905 and r340836, making benchmarks build by
default everywhere.

llvm-svn: 341716

- Remove duplication: Both TestingGuide and TestSuiteMakefileGuide
  would give a similar overview over the test-suite.
- Present cmake/lit as the default/normal way of running the test-suite:
- Move information about the cmake/lit testsuite into the new
  TestSuiteGuide.rst file. Mark the remaining information in
  TestSuiteMakefilesGuide.rst as deprecated.
- General simplification and shorting of language.
- Remove paragraphs about tests known to fail as everything should pass
  nowadays.
- Remove paragraph about zlib requirement; it's not required anymore
  since we copied a zlib source snapshot into the test-suite.
- Remove paragraph about comparison with "native compiler". Correctness is
  always checked against reference outputs nowadays.
- Change cmake/lit quickstart section to recommend `pip` for installing
  lit and use `CMAKE_C_COMPILER` and a cache file in the example as that
  is what most people will end up doing anyway. Also a section about
  compare.py to quickstart.
- Document `Bitcode` and `MicroBenchmarks` directories.
- Add section with commonly used cmake configuration options.
- Add section about showing and comparing result files via compare.py.
- Add section about using external benchmark suites.
- Add section about using custom benchmark suites.
- Add section about profile guided optimization.
- Add section about cross-compilation and running on external devices.

Differential Revision: https://reviews.llvm.org/D51465

llvm-svn: 341260

The problems with benchmark build should be fixed now, but Windows
buildbots still run into errors seemingly because of the bug in
clang-cl. Because of that, benchmark shouldn't be built on Windows at
this point.

llvm-svn: 340905

Although the benchmark regex-related build issue seems to be
fixed, it appears that benchmark library triggers some stage 2 clang-cl
bugs:

http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/13495/steps/build%20stage%202/logs/stdio

The only sensible option now is to prevent benchmark library from
building in the default configuration.

llvm-svn: 340836

This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any
project could use it for benchmark generation. A dummy benchmark is
added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of
the build process.

The current version does not utilize LLVM LNT and LLVM CMake
infrastructure, but that might be sufficient for most users. Two
introduced CMake variables:

* `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark
  targets
* `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated
  benchmark targets to the list of default LLVM targets (i.e. if `ON`
  benchmarks will be built upon standard build invocation, e.g. `ninja` or
  `make` with no specific targets)

List of modifications:

* `BENCHMARK_ENABLE_TESTING` is disabled
* `BENCHMARK_ENABLE_EXCEPTIONS` is disabled
* `BENCHMARK_ENABLE_INSTALL` is disabled
* `BENCHMARK_ENABLE_GTEST_TESTS` is disabled
* `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled

Original discussion can be found here:
http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html

Reviewed by: dberris, lebedev.ri

Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines,
dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits

Differential Revision: https://reviews.llvm.org/D50894

llvm-svn: 340809

This new JIT event listener supports generating profiling data for
the linux 'perf' profiling tool, allowing it to generate function and
instruction level profiles.

Currently this functionality is not enabled by default, but must be
enabled with LLVM_USE_PERF=yes.  Given that the listener has no
dependencies, it might be sensible to enable by default once the
initial issues have been shaken out.

I followed existing precedent in registering the listener by default
in lli. Should there be a decision to enable this by default on linux,
that should probably be changed.

Please note that until https://reviews.llvm.org/D47343 is resolved,
using this functionality with mcjit rather than orcjit will not
reliably work.

Disregarding the previous comment, here's an example:

$ cat /tmp/expensive_loop.c

bool stupid_isprime(uint64_t num)
{
        if (num == 2)
                return true;
        if (num < 1 || num % 2 == 0)
                return false;
        for(uint64_t i = 3; i < num / 2; i+= 2) {
                if (num % i == 0)
                        return false;
        }
        return true;
}

int main(int argc, char **argv)
{
        int numprimes = 0;

        for (uint64_t num = argc; num < 100000; num++)
        {
                if (stupid_isprime(num))
                        numprimes++;
        }

        return numprimes;
}

$ clang -ggdb -S -c -emit-llvm /tmp/expensive_loop.c -o
/tmp/expensive_loop.ll

$ perf record -o perf.data -g -k 1 ./bin/lli -jit-kind=mcjit /tmp/expensive_loop.ll 1

$ perf inject --jit -i perf.data -o perf.jit.data

$ perf report -i perf.jit.data
-   92.59%  lli      jitted-5881-2.so                   [.] stupid_isprime
     stupid_isprime
     main
     llvm::MCJIT::runFunction
     llvm::ExecutionEngine::runFunctionAsMain
     main
     __libc_start_main
     0x4bf6258d4c544155
+    0.85%  lli      ld-2.27.so                         [.] do_lookup_x

And line-level annotations also work:
       │              for(uint64_t i = 3; i < num / 2; i+= 2) {
       │1 30:   movq   $0x3,-0x18(%rbp)
  0.03 │1 38:   mov    -0x18(%rbp),%rax
  0.03 │        mov    -0x10(%rbp),%rcx
       │        shr    $0x1,%rcx
  3.63 │     ┌──cmp    %rcx,%rax
       │     ├──jae    6f
       │     │                if (num % i == 0)
  0.03 │     │  mov    -0x10(%rbp),%rax
       │     │  xor    %edx,%edx
 89.00 │     │  divq   -0x18(%rbp)
       │     │  cmp    $0x0,%rdx
  0.22 │     │↓ jne    5f
       │     │                        return false;
       │     │  movb   $0x0,-0x1(%rbp)
       │     │↓ jmp    73
       │     │        }
  3.22 │1 5f:│↓ jmp    61
       │     │        for(uint64_t i = 3; i < num / 2; i+= 2) {

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D44892

llvm-svn: 337789

It used to symlink dsymutil to llvm-dsymutil, but after r327790 llvm's dsymutil
binary is now called dsymutil without prefix.

r327792 then reversed the direction of the symlink if
LLVM_INSTALL_CCTOOLS_SYMLINKS was set, but that looks like a buildfix and not
like something anyone should need.

https://reviews.llvm.org/D45966

llvm-svn: 330727

Summary: Fixes PR37053.

Reviewers: uabelho, gchatelet

Subscribers: mgorny, tschuett, llvm-commits

Differential Revision: https://reviews.llvm.org/D45436

llvm-svn: 329781

Now that almost all functionality of Apple's dsymutil has been
upstreamed, the open source variant can be used as a drop in
replacement. Hence we feel it's no longer necessary to have the llvm
prefix.

Differential revision: https://reviews.llvm.org/D44527

llvm-svn: 327790

Add a `LLVM_INSTALL_CCTOOLS_SYMLINKS` to mirror
`LLVM_INSTALL_BINUTILS_SYMLINKS`.  For now, this allows us to create
symlinks for `dsymutil` to `llvm-dsymutil`.  This option is off by
default, but the user can enable it.

llvm-svn: 326381

Patch by Matthew Davis!

Differential Revision: https://reviews.llvm.org/D41757

llvm-svn: 323357

The LLVM tools can be used as a replacement for binutils, in which case
it's convenient to create symlinks with the binutils names. Add support
for these symlinks in the build system. As with any other llvm tool
symlinks, the user can limit the installed symlinks by only adding the
desired ones to `LLVM_TOOLCHAIN_TOOLS`.

Differential Revision: https://reviews.llvm.org/D39530

llvm-svn: 317272

llvm-svn: 313768

Summary:
This reduces the number of build actions after a no-op commit from
thousands to about six, which should be acceptable. If six actions is
still too many, developers can disable the LLVM_APPEND_VC_REV cmake
option.

llvm-config.h is a widely included header that should rarely change.
Before this patch, it would change after every re-configure. Very few
users of llvm-config.h need to know the precise version, and those that
do can migrate to incorporating LLVM_REVISION as provided by
llvm/Support/VCSRevision.h.

This should bring LLVM back to the behavior that it had before r306858
from June 30 2017. Most LLVM tools will now print a version string like
"6.0.0svn" instead of "6.0.0-git-c40c2a23de4".

Fixes PR34308

Reviewers: pcc, rafael, hans

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D37272

llvm-svn: 312043

Reviewers: beanz, mehdi_amini

Reviewed By: beanz

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D35080

llvm-svn: 307560

Working with git on a branch I find it really annoying that committing
a change causes ninja to think that stuff needs to be rebuilt.

With this change at least nothing in llvm needs to be rebuild when
something is committed.

llvm-svn: 306858

Fixed "most platform" to read "most platforms", and changed "are not
using the same" to "use different" as a drive-by.

llvm-svn: 303487

llvm-svn: 292752

Summary:
This string parameter is passed to -fuse-ld when linking. It can be
an absolute path to your custom linker, otherwise clang will look for
`ld.{name}`.

Reviewers: davide, tejohnson, pcc

Subscribers: llvm-commits, mgorny

Differential Revision: https://reviews.llvm.org/D28738

llvm-svn: 292047

Add an explicit LLVM_ENABLE_DIA_SDK option to control building support
for DIA SDK-based debugging. Control its value to match whether DIA SDK
support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB).

Its value is needed for LLDB to determine whether to run tests requiring
DIA support. Currently it is obtained from llvm/Config/config.h;
however, this file is not available for standalone builds. Following
this change, LLDB will be modified to use the value from LLVMConfig.

Differential Revision: https://reviews.llvm.org/D26255

llvm-svn: 290818

[doc] Add mention of the difference in optimization level between Release and RelWithDebInfo in Cmake.rst

This is surprising to many people.

llvm-svn: 290556

Summary:
This allows to have clang and llvm and the other subprojects
side-by-side instead of nested. This can be used with the monorepo or
multiple repos.

It will help having a single set of sources checked out but allows to
have a build directory with llvm and another one with llvm+clang.
Basically it abstracts LLVM_EXTERNAL_xxxx_SOURCE_DIR making it more
convenient by adopting a convention.

Reviewers: bogner, beanz, jlebar

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D26365

llvm-svn: 286162

Support overriding the Doxygen & OCamldoc install directories,
and provide a more FHS-compliant defaults for both of them. This extends
r282240 that added this override for Sphinx-built documentation.

LLVM_INSTALL_DOXYGEN_HTML_DIR and LLVM_INSTALL_OCAMLDOC_HTML_DIR are
added, to control the location where Doxygen-generated and
OCamldoc-generated HTML docs are installed appropriately. They both
specify CMake-style install paths, and therefore can either by relative
to the install prefix or absolute.

The new defaults are subdirectories of share/doc/llvm, and replace
the previous directories of 'docs/html' and 'docs/ocaml/html' that
resulted in creating invalid '/usr/docs' that furthermore lacked proper
namespacing for the LLVM package. The new defaults are consistent with
the ones used for Sphinx HTML documentation, differing only in the last
component. Since the 'html' subdirectory is already used for Sphinx
docs, the 'doxygen-html' and 'ocaml-html' directories are used instead.

Differential Revision: https://reviews.llvm.org/D24935

llvm-svn: 282536

Provide ${PROJECT}_INSTALL_SPHINX_HTML_DIR variables (e.g.
LLVM_INSTALL_SPHINX_HTML_DIR) to override Sphinx HTML doc install
directory.

Bug: https://llvm.org/bugs/show_bug.cgi?id=23780

Differential Revision: https://reviews.llvm.org/D23757

llvm-svn: 282240

This is a partial revert of r280013. Brad King pointed out these variable names are matching CMake conventions, so we should preserve them.

I've also added a direct mapping of the LLVM_*_DIR variables which we need to make projects support building in and out of tree.

llvm-svn: 280380

With the runtimes build we're trying to use LLVMConfig.cmake as a way of providing LLVM_* variables that are needed to behave as if the project is building in tree. To make this work we need to rename two variables by dropping the "S" from the end. This makes the variables match the in-tree names.

This renames:
LLVM_INCLUDE_DIRS -> LLVM_INCLUDE_DIR
LLVM_LIBRARY_DIRS -> LLVM_LIBRARY_DIR

The versions ending in S are not used in-tree anywhere. This also cleans up LLVM_LIBRARY_DIR being set to the same value with and without the "S".

llvm-svn: 280013

llvm-svn: 273570

llvm-svn: 271452

The new option makes it possible to build external projects as part of
the llvm build without copying (or symlinking) then into llvm/tool with
specifying a few additional cmake variables.

Example usage (2 additional project called foo and bar):
-DLLVM_EXTERNAL_PROJECTS="Foo;Bar"
-DLLVM_EXTERNAL_FOO_SOURCE_DIR=/src/foo
-DLLVM_EXTERNAL_BAR_SOURCE_DIR=/src/bar

Note: This is the extension of the approach we already support for
clang/lldb/poly with adding an option to specify additional supported
projects.

Differential revision: http://reviews.llvm.org/D20838

llvm-svn: 271440